Règles de contrôle

Toutes les règles que les contrôles appliquent à vos schémas, dans votre navigateur, sans IA et sans crédit. Chaque fiche donne la sévérité par défaut, pourquoi la règle compte et comment résoudre le constat. Les textes sont ceux que l’app affiche sur un constat.

Toutes les règles

Dans l’app, la sévérité s’écrit ÉLEVÉE, MOYENNE, FAIBLE ou INFO. Pour traiter un constat, voir Lancer les contrôles et traiter les constats.

Fiabilité

REL-01 Point de défaillance unique

• Sévérité : Élevée si l’élément est critique, sinon moyenne.
• Pourquoi c’est important : Une seule panne arrête l’élément et tous les flux qui en dépendent.
• Comment corriger : Exécutez deux répliques ou plus réparties sur plusieurs zones, utilisez une offre gérée à haute disponibilité intégrée, ou indiquez sa haute disponibilité : actif-passif, primaire et réplica, ou actif-actif.

REL-02 Redondance de zone absente

• Sévérité : Moyenne.
• Pourquoi c’est important : Une panne de zone arrête toutes les répliques à la fois.
• Comment corriger : Indiquez deux zones ou plus, ou répartissez les répliques sur les zones.

REL-04 Reprise après sinistre non indiquée

• Sévérité : Moyenne.
• Pourquoi c’est important : Sans mode de reprise, RPO et RTO indiqués, la reprise après la perte d’une région est improvisée.
• Comment corriger : Indiquez la reprise après sinistre des instances du stockage principal : son mode, son RPO et son RTO.

REL-06 Lien hybride non redondant

• Sévérité : Élevée.
• Pourquoi c’est important : Un seul tunnel ou circuit est un point de défaillance unique pour tous les appels hybrides.
• Comment corriger : Ajoutez un deuxième lien, ou donnez au lien un deuxième tunnel ou circuit.

Intégration

PERF-01 Longue chaîne synchrone

• Sévérité : Moyenne ; élevée quand la chaîne dépasse 5 sauts.
• Pourquoi c’est important : La latence et la probabilité de panne s’additionnent le long d’une chaîne synchrone ; un saut lent bloque tous les appelants.
• Comment corriger : Coupez la chaîne par une messagerie asynchrone, un cache ou des données répliquées, ou regroupez des services trop fins.

PERF-02 Cycle synchrone

• Sévérité : Élevée.
• Pourquoi c’est important : Un cycle synchrone est un monolithe distribué : risque d’interblocage et d’amplification des reprises.
• Comment corriger : Cassez le cycle avec un événement, ou déplacez la logique partagée d’un seul côté.

PERF-03 Appels répétés à travers une frontière

• Sévérité : Moyenne.
• Pourquoi c’est important : Des échanges bavards à travers une frontière multiplient la latence et le trafic sortant à chaque requête.
• Comment corriger : Regroupez les appels, mettez la réponse en cache, ou déplacez la boucle de l’autre côté de la frontière.

PERF-04 Politique de résilience absente

• Sévérité : Moyenne.
• Pourquoi c’est important : Sans délai d’expiration, une dépendance lente épuise l’appelant ; rejouer un appel non idempotent duplique ses effets.
• Comment corriger : Fixez un délai d’expiration (et un disjoncteur quand la cible est partagée) ; rendez idempotentes les opérations rejouées.

PERF-05 Base de données partagée

• Sévérité : Moyenne.
• Pourquoi c’est important : Un stockage écrit par plusieurs équipes les couple par son schéma.
• Comment corriger : Donnez un seul responsable au stockage et exposez ses données par une API ou des événements.

PERF-07 Intégration directe qui contourne la plateforme d’intégration

• Sévérité : Moyenne.
• Pourquoi c’est important : Les liaisons point à point entre applications multiplient les couplages et échappent à ce que fournit la plateforme : contrats, sécurité, supervision et réutilisation.
• Comment corriger : Faites passer l’intégration par la plateforme : pointez la relation vers son entrée (la passerelle API pour un appel, le broker ou un canal pour un événement, le service d’intégration pour les fichiers et les lots) et ajoutez le saut de la plateforme vers l’autre application, ou faites-la passer par un canal de la plateforme.

Sécurité

SEC-01 Point d’entrée sans authentification

• Sévérité : Élevée.
• Pourquoi c’est important : Un point d’entrée joignable depuis Internet sans authentification (OWASP API2:2023).
• Comment corriger : Indiquez l’authentification de la cible (OpenID Connect, OAuth 2.0, TLS mutuel…) ou de la relation.

SEC-02 Entrée qui contourne la périphérie

• Sévérité : Élevée.
• Pourquoi c’est important : Le trafic venu d’Internet devrait passer par une passerelle API, un WAF ou un répartiteur de charge avant d’atteindre le calcul.
• Comment corriger : Faites passer l’appel par la passerelle API ou le WAF, et retirez les adresses IP publiques du calcul.

SEC-03 Frontière franchie sans chiffrement

• Sévérité : Élevée.
• Pourquoi c’est important : Des données qui franchissent une frontière en clair peuvent être lues ou modifiées (STRIDE : altération, divulgation d’informations).
• Comment corriger : Utilisez TLS (HTTPS, SFTP, LDAPS, AMQPS), mTLS ou un tunnel IPsec, et indiquez le chiffrement.

SEC-07 Service PaaS joignable publiquement

• Sévérité : Moyenne.
• Pourquoi c’est important : Le service reste joignable depuis Internet alors que ses consommateurs sont sur un réseau privé.
• Comment corriger : Désactivez son accès public et ajoutez-lui un point d’accès privé dans le réseau des consommateurs.

Données

DATA-01 Stockage sans sauvegarde

• Sévérité : Élevée si l’élément est critique, sinon moyenne.
• Pourquoi c’est important : Sans sauvegarde, une perte de données est irrécupérable ; un sinistre régional emporte aussi les sauvegardes de la même région.
• Comment corriger : Indiquez la sauvegarde du stockage : sa fréquence, sa rétention et une copie dans une autre région.

DATA-03 Résidence des données non respectée

• Sévérité : Élevée.
• Pourquoi c’est important : Stocker des données hors de leur zone géographique autorisée enfreint les obligations de résidence.
• Comment corriger : Déplacez l’instance dans une région de la zone de résidence, ou corrigez la résidence.

DATA-05 Hygiène asynchrone

• Sévérité : Moyenne.
• Pourquoi c’est important : Sans canal des messages en échec, un message toxique bloque ou disparaît ; une nouvelle livraison duplique les effets ; un canal à un seul côté cache un flux manquant.
• Comment corriger : Donnez au canal un canal des messages en échec, rendez idempotents les consommateurs au moins une fois, et modélisez l’émetteur ou l’abonnement manquant.

Réseau

NET-01 Plages d’adresses qui se chevauchent

• Sévérité : Élevée quand les deux sont reliés (même réseau, un flux, un lien ou une route entre eux), sinon moyenne.
• Pourquoi c’est important : Des préfixes qui se chevauchent ne peuvent ni être appairés ni être routés l’un vers l’autre, et le trafic vers la plage commune ne va qu’à l’un d’eux.
• Comment corriger : Réadressez un côté depuis une plage libre du plan d’adressage, ou traduisez les adresses (NAT) à la frontière et indiquez-le.

NET-02 Sous-réseau hors de son réseau

• Sévérité : Élevée.
• Pourquoi c’est important : Un sous-réseau doit se trouver dans l’espace d’adresses de son réseau ; sinon le déploiement échoue ou les adresses sont injoignables.
• Comment corriger : Donnez au sous-réseau un préfixe dans le réseau, ou ajoutez l’espace d’adresses au réseau.

NET-03 Route absente

• Sévérité : Élevée.
• Pourquoi c’est important : Sans route, les paquets sont perdus ou prennent le chemin par défaut, en contournant le pare-feu qui devait les inspecter.
• Comment corriger : Ajoutez une route avec le préfixe de destination sur le sous-réseau, sa table de routage ou son réseau, ou appairez les deux réseaux.

NET-04 Port d’administration exposé à Internet

• Sévérité : Élevée.
• Pourquoi c’est important : Les ports d’administration joignables depuis Internet sont la première cible des attaques par force brute et des exploits.
• Comment corriger : Passez par un bastion, un VPN ou un point de terminaison privé, et filtrez le port en périphérie.

NET-05 Flux entre zones non chiffré

• Sévérité : Moyenne.
• Pourquoi c’est important : La segmentation limite qui peut joindre une zone, pas qui peut lire le trafic entre les zones.
• Comment corriger : Utilisez TLS ou mTLS entre les zones, ou un tunnel IPsec, et indiquez le chiffrement.

Exploitation

OPS-01 Aucune destination de télémétrie

• Sévérité : Moyenne.
• Pourquoi c’est important : Personne ne voit les pannes qu’aucun journal, aucune métrique ni aucune trace n’enregistre.
• Comment corriger : Déployez un élément de supervision (journaux, métriques et traces) dans l’environnement.

Hygiène

HYG-01 Métadonnées manquantes

• Sévérité : Faible.
• Pourquoi c’est important : La notation C4 attend que chaque boîte et chaque ligne dise ce qu’elle est et sur quoi elle tourne.
• Comment corriger : Renseignez la description ou la technologie manquante.

HYG-02 Libellé trop vague

• Sévérité : Faible.
• Pourquoi c’est important : Un verbe générique ne dit ni ce qui circule ni pourquoi.
• Comment corriger : Décrivez l’interaction par un groupe verbal, par exemple « Demande des devis complets à ».

HYG-03 Élément isolé

• Sévérité : Faible.
• Pourquoi c’est important : Un élément sans relation a perdu ses flux ou ne fait plus partie de l’architecture.
• Comment corriger : Reliez-le, ou retirez-le.

HYG-04 Flux manquant

• Sévérité : Moyenne.
• Pourquoi c’est important : Le modèle et ses scénarios, processus ou parcours de connexion ne concordent pas.
• Comment corriger : Ajoutez la relation manquante au modèle, ou marquez comme ad hoc une étape voulue.

HYG-05 Nommage

• Sévérité : Info.
• Pourquoi c’est important : Des noms en double désorientent les lecteurs ; des sigles non expliqués les excluent.
• Comment corriger : Renommez l’un des éléments, ou définissez le sigle dans le glossaire.

HYG-06 Qualité de la vue

• Sévérité : Info.
• Pourquoi c’est important : Une vue surchargée ou qui mélange les niveaux se lit mal (liste de contrôle C4).
• Comment corriger : Découpez la vue, ou repliez ou excluez des éléments.

Standards

STD-01 Technologie en fin de vie ou proche de sa fin de vie

• Sévérité : Élevée après la fin de vie ; moyenne après la fin de support ; faible quand la fin de vie arrive sous 180 jours.
• Pourquoi c’est important : Un logiciel en fin de vie ne reçoit plus de correctifs de sécurité ; hors support, les correctifs deviennent lents ou payants.
• Comment corriger : Passez à une version prise en charge (le catalogue indique la remplaçante), ou consignez une exception limitée dans le temps avec des mesures compensatoires.

STD-02 Technologie au radar « Suspendre »

• Sévérité : Faible.
• Pourquoi c’est important : L’espace de travail a décidé de ne plus démarrer de travail avec cette technologie.
• Comment corriger : Choisissez une technologie des anneaux Adopter ou Essayer, ou consignez une exception qui explique pourquoi celle-ci reste.

STD-03 Technologie hors radar

• Sévérité : Info.
• Pourquoi c’est important : Une technologie absente du radar n’a ni anneau ni dates de cycle de vie : personne n’a décidé de l’utiliser, et sa fin de vie passe inaperçue.
• Comment corriger : Ajoutez-la au radar technologique avec un anneau, ou écrivez la technologie comme le radar la nomme (un alias), ou consignez une exception.

Gouvernance

GOV-01 Exception expirée

• Sévérité : Élevée.
• Pourquoi c’est important : Une exception expirée ne couvre plus son écart : le risque qu’elle acceptait n’est plus géré.
• Comment corriger : Renouvelez l’exception avec une nouvelle échéance et vérifiez ses mesures compensatoires, clôturez-la, ou supprimez l’écart.

GOV-02 Exception à revoir

• Sévérité : Moyenne quand la date de revue est passée ; faible quand l’exception expire sous 30 jours.
• Pourquoi c’est important : Les exceptions sont limitées dans le temps : les revoir avant leur échéance garde le registre fidèle.
• Comment corriger : Revoyez l’exception avec son responsable : renouvelez-la, clôturez-la, ou planifiez le travail qui supprime l’écart.

GOV-03 Condition en retard

• Sévérité : Moyenne.
• Pourquoi c’est important : L’approbation reposait sur cette condition ; tant qu’elle n’est pas remplie, l’approbation est incomplète.
• Comment corriger : Remplissez la condition et marquez-la remplie, convenez d’une nouvelle échéance avec le comité, ou levez-la avec une note.

GOV-04 Modifié depuis la décision de revue

• Sévérité : Info.
• Pourquoi c’est important : Le comité a approuvé une autre révision : les modifications faites depuis n’ont pas été relues.
• Comment corriger : Soumettez les modifications en revue, ou consignez une nouvelle décision sur cette révision.