Postmortems orientés par l'IA et apprentissage passif
Pourquoi les équipes IA continuent de répéter les mêmes erreurs
La plupart des incidents d’IA ne proviennent pas d’une seule invite catastrophique. Ils proviennent d’une chaîne de petits ratés que personne n’écrit au moment où ils se produisent.
L’apprentissage passif est le muscle manquant. Vous ne l’obtenez que lorsque chaque incident laisse derrière lui des artefacts faciles à trouver, à comparer et à réutiliser.
Cinq éléments d'un post-mortem utile à l'ère de l'IA
| Element | Que capturer | Pourquoi c'est important |
|---|---|---|
| Trigger | Le chemin utilisateur exact, l'invite ou la validation qui a exposé le problème | Supprime la narration rétrospective |
| Comportement observé | Journaux, traces, captures d'écran et vérifications échouées | Empêche la dérive de la mémoire |
| Dossier de décision | Ce qui a été considéré, rejeté et accepté | Rend les compromis visibles |
| Preuve de réparation | Preuve que le correctif sélectionné fonctionne dans des conditions qui ont échoué auparavant | Arrête les réclamations « résolues en théorie » |
| Mise à jour du garde-corps | Nouveau test, règle de charpie, étape du runbook ou porte de stratégie | Convertit une douleur ponctuelle en prévention reproductible |
L'apprentissage passif est un système, pas une réunion
L'expression « nous avons appris de cela » n'est vraie que lorsque l'apprentissage survit aux changements de personnel et au temps.
Une boucle d'apprentissage passif pratique : capturez une chronologie, capturez côte à côte les états d'échec et les états corrigés, classifiez le modèle d'échec, attachez un mécanisme de prévention obligatoire et vérifiez ce mécanisme lors du prochain changement similaire.
À quoi ressemblent les post-mortems d’IA matures
Les équipes expérimentées traitent les preuves d’incidents comme un artefact de première classe et non comme une tâche de nettoyage. Ils distinguent l’erreur de modèle de l’erreur de processus humain. Ils favorisent rapidement les pannes récurrentes des portails automatisés.
Lorsqu’un élément post-mortem manque, le post-mortem devient une fiction historique. Les modèles récurrents ci-dessous apparaissent à plusieurs reprises dans les équipes et les fournisseurs de cloud.
| Pattern | Symptom | Cause première | Contre-mesure forte |
|---|---|---|---|
| Fuite de portée rapide | L'IA modifie les fichiers en dehors des limites prévues | Cadrage des tâches lâche et surface d’examen faible | Vérifications de différences étendues et listes d'autorisation de fichiers explicites |
| Faux tests verts | CI réussit mais le comportement est mauvais | Les assertions testent les détails de la mise en œuvre, pas les résultats | Assertions au niveau du contrat et vérifications d'échec en premier |
| Logique de repli dangereuse | Le repli silencieux masque les erreurs | Branches « Continuez à exécuter » sans observabilité | Bilans d’erreur structurés et télémétrie obligatoire |
| Dérive après fusion | La qualité de la base de code régresse quelques jours plus tard | Correctif fusionné sans synchronisation des politiques ou des documents | Vérification post-fusion et porte de documentation |
Créer une bibliothèque post-mortem que les développeurs utilisent réellement
Si la recherche d'incidents antérieurs prend plus de temps que la recréation du bug, personne ne consultera les archives.
Une bibliothèque utilisable prend en charge la recherche par modèle d'échec, de courtes sections « ce qu'il faut copier » avec des vérifications prêtes à l'emploi, des liens à partir de runbooks et de modèles PR, et une condition de fermeture qui confirme que la prévention a été intégrée aux outils.
Un kit de démarrage pratique pour les équipes
- Un modèle post-mortem qui nécessite des liens de preuves.
- Une taxonomie avec moins de 12 modèles d'échec.
- Une politique selon laquelle chaque incident doit donner lieu à une action de prévention.
- Une analyse mensuelle pour la fréquence des motifs répétés.
- Une révision de qualité légère pour retirer les leçons obsolètes.
Références
- Qodo (2025) État de la qualité du code d’IA en 2025
- METR (2025) Les outils d'IA ont rendu les développeurs expérimentés 19 % plus lents
- Martin Fowler / Kief Morris (2025) Jusqu’où pouvons-nous pousser l’autonomie de l’IA dans la génération de code ?
- Simon Willison (2025) Modèles d'ingénierie agentique
- Addy Osmani (2026) L'IA écrit le code plus rapidement. Votre travail consiste encore à prouver que cela fonctionne.
- Équipe Microsoft .NET (2026) Dix mois avec Copilot Coding Agent dans dotnet/runtime