Carte des risques et pratiques
Comment utiliser cette carte
Cette carte ne remplace pas l'analyse d'impact. Elle aide à partir d'un risque concret pour retrouver les mécanismes du handbook qui posent les bonnes questions. Un changement peut relever de plusieurs lignes : une migration de données touchant une API publique et une règle financière demande par exemple des protections de données, de contrat, de réversibilité et d'observabilité.
La colonne « première question » sert de point d'entrée. Les chapitres indiqués ne sont pas une procédure à suivre dans l'ordre : ils donnent le raisonnement et les pratiques à adapter au contexte.
| Risque observé | Première question | Mécanismes de maîtrise | Chapitres de référence |
|---|---|---|---|
| Règle métier ambiguë | Quel résultat doit rester vrai, et dans quels cas ? | Modèle de domaine, exemples, invariants, tests de décision | Découvrir, Modéliser, Tests comme preuves |
| Régression sur données historiques | Quelle décision passée doit être préservée ou corrigée ? | Caractérisation, migration additive, comptes, réconciliation | Données, Réversibilité, Migrations |
| Effet irréversible ou externe | Que survivra à un rollback de code ? | Limitation d'exposition, compensation, audit, plan de réparation | Impact, Livraison progressive, Réversibilité |
| Contrat ou API partagé | Qui dépend de ce comportement et à quel rythme évolue-t-il ? | Compatibilité, contrat versionné, tests de contrat, dépréciation | Contrats évolutifs, Tester les contrats |
| Événement, retry, concurrence | Que se passe-t-il en cas de doublon, retard ou conflit ? | Idempotence, version, horodatage, ordre explicite, réconciliation | Temps et concurrence, Données |
| Dépendance lente ou indisponible | Quel résultat utilisateur peut être dégradé sans devenir faux ? | Timeout, limite de concurrence, dégradation, SLO, runbook | Couplage, Fiabilité, Incidents |
| Faible observabilité | Comment saurons-nous que l'effet est mauvais, pour qui et depuis quand ? | Indicateur de résultat, traces, logs structurés, alerte actionnable | Observabilité, Impact |
| Exposition de sécurité | Quel actif, acteur ou chemin d'abus est en jeu ? | Modèle de menace, moindre privilège, audit, réponse préparée | Sécurité, Vie privée |
| Dépendance ou build non fiable | Pouvons-nous identifier ce qui a été livré et corriger vite ? | Provenance, inventaire, artefact immuable, exception datée | Supply chain, CI |
| Configuration ou flag dangereux | Qui peut modifier ce comportement, et comment sera-t-il retiré ? | Schéma, droits, audit, cohorte, seuil, échéance de nettoyage | Configuration et flags |
| Capacité, performance ou coût | Quel parcours limite le service ou sa viabilité ? | Modèle de charge, SLO, limite, dégradation, coût par usage | Qualité non fonctionnelle, Capacité et coût |
| Accessibilité insuffisante | Le parcours est-il réellement perceptible, opérable et compréhensible ? | Critères de comportement, composants, tests automatisés et évaluation humaine | Accessibilité |
| Coordination d'équipe excessive | Quelle décision exige toujours les mêmes handoffs, et pourquoi ? | Frontière, contrat, mission d'équipe, plateforme, délégation | Frontières, Équipes |
| Connaissance concentrée | Qui peut agir si l'expert n'est pas disponible ? | Pairing, rotation, runbook, exemples, parcours de capacité | Responsabilité, Compétences |
| Legacy difficile à modifier | Quelle contrainte cause le plus de dommage maintenant ? | Caractérisation, point de couture, trajectoire, transition mesurée | Legacy, Créer de la sécurité, Moderniser |
| Décision assistée par IA | Quel contexte est partagé et quelle preuve valide le résultat ? | Minimisation du contexte, compréhension humaine, preuves indépendantes | Ingénierie assistée par IA |
Lire plusieurs risques ensemble
Un changement important peut être décrit comme une combinaison de risques. Par exemple, une nouvelle règle d'autorisation sur une API partenaire implique au moins quatre angles : la règle doit être comprise et testée ; le contrat doit rester compatible ; les accès et logs doivent protéger les données ; le déploiement doit être observable et récupérable. La carte aide à ne pas confondre la taille du diff avec la profondeur de l'analyse nécessaire.
Choisir les deux ou trois lignes les plus pertinentes, puis écrire les mécanismes retenus dans la fiche de changement. Cette pratique est plus utile qu'une checklist exhaustive : elle relie l'effort de vérification au mécanisme réel du risque.
À retenir
La maîtrise du risque n'est pas une collection de pratiques à appliquer uniformément. C'est la capacité à reconnaître le mécanisme d'un danger, choisir les barrières adaptées et savoir quels chapitres approfondir lorsque le changement dépasse le contexte local.