📈 7 — Learn
Learn observe les résultats en production, ouvre des tickets et améliore le contexte et les contrôles.
Objectif
| Entrée | Sortie | Responsable |
|---|---|---|
| Télémétrie de production, comportement des utilisateurs, incidents, coûts | Alertes précoces, hypothèses validées ou invalidées, nouveaux tickets de backlog, amélioration du Contexte persistant et des Contrôles déterministes | QA et mainteneur |
Ce qui est observé
| Dimension | Exemples | Alimente |
|---|---|---|
| Résultat métier (Outcome) | La métrique de résultat engagée dans le ticket de backlog de 1 — Triage | Cela valait-il la peine d’être construit ? |
| Santé du système | Latence, taux d’erreur, saturation, disponibilité | Réponse aux incidents |
| Flux (Flow) | Délai de mise en œuvre (lead time), fréquence de déploiement, taux d’échec des changements, temps de rétablissement | Métriques |
| Levier IA | Taux d’acceptation, taux de reprise (rework), coût par changement | Évaluation des modèles et des prompts |
| Coût | Dépenses d’infrastructure et d’utilisation des modèles par squad et par fonctionnalité | Priorisation |
Surveillance prédictive
L’IA compare la télémétrie aux références et à la métrique de Triage. Elle signale les anomalies et dégradations : hausse des erreurs, saturation ou dérive des coûts.
| Étape | Ce qui se passe | Qui décide |
|---|---|---|
| Détecter | L’IA signale une anomalie ou une tendance qui se dirige vers un seuil | L’IA propose |
| Expliquer | L’IA corrèle les journaux (logs), traces, déploiements et diffs récents pour identifier la cause probable | Le QA et mainteneur confirme |
| Agir | Atténuer tôt, ouvrir un ticket de backlog dans 1 — Triage afin de renforcer le contrôle qui aurait dû intercepter le problème | Le QA et mainteneur décide ; les seuils de rollback de 6 — Release continuent de déclencher le rollback automatique |
Ce que la surveillance apprend peut être réinjecté dans le Contexte persistant, et les signaux manqués doivent devenir des Contrôles déterministes plus stricts.
Le registre des hypothèses (Hypothesis ledger)
Chaque élément de travail ayant défini une métrique de résultat est examiné à l’issue de sa fenêtre d’observation.
| Verdict | Signification | Action suivante |
|---|---|---|
| Validée | La métrique a évolué comme prévu | Poursuivre l’investissement, retirer le feature flag |
| Non concluante | Aucun mouvement détectable | Décider : itérer une fois ou supprimer |
| Invalidée | La métrique n’a pas bougé ou a évolué dans le mauvais sens | Supprimer la fonctionnalité, documenter l’enseignement |
Supprimez les fonctionnalités invalidées. Le code mort complique chaque changement futur.
Incidents
- Détecter — alerte ou signalement client.
- Atténuer — feature flag, rollback ou correctif en avant (forward fix). L’atténuation précède toujours le diagnostic.
- Diagnostiquer — l’IA corrèle les journaux, traces, déploiements et diffs récents ; les humains concluent.
- Réparer — ajouter un test qui reproduit le défaut, confirmer qu’il échoue, puis corriger le défaut et confirmer que le test passe (Prove).
- Apprendre — passer l’incident en revue dans un délai de cinq jours ouvrés.
Durcissement des Contrôles déterministes
Pour chaque défaut, rollback ou quasi-incident, demandez : quel contrôle aurait dû l’intercepter ?
- Une vérification manquait → ajouter un garde (guard), un jalon (gate), un contrat (contract) ou une sonde (probe).
- Un signal est arrivé trop tard → ajouter une sonde plus précoce.
Agents et skills
L’étape Learn referme la boucle de rétroaction du développement en s’appuyant sur des primitives publiées par coding-pal :
Primitives d’analyse et de gouvernance
- Un agent Learn Analyst traite les exports de télémétrie, corrèle l’historique des déploiements, évalue les métriques de résultat des hypothèses et prépare les revues d’incidents.
- Une instruction learn impose la discipline par la preuve : l’atténuation précède le diagnostic, les correctifs exigent d’abord un test en échec, les fonctionnalités invalidées sont supprimées et seuls les humains enregistrent les verdicts.
Compétences de gestion des incidents et de télémétrie de production
- Une compétence telemetry-scan analyse les métriques temporelles pour identifier les anomalies précoces, les tendances de dégradation et les franchissements de seuils au regard des déploiements précédents.
- Une compétence incident-record formate et valide les dossiers
docs/incidents/: elle garantit que les horodatages d’atténuation précèdent le diagnostic, lie les tests de reproduction en échec et planifie les revues rétrospectives.
Compétences de suivi des hypothèses et d’entretien du contexte
- Une compétence hypothesis-ledger maintient
specs/learn/hypotheses.md, en comparant les métriques de production observées aux cibles déclarées et en proposant des verdicts (Validée, Non concluante, Invalidée) soumis à la décision du Product Owner. - Une compétence context-health audite les jeux d’instructions et analyse les journaux de corrections pour suggérer l’ajout ou l’élagage d’artefacts du Contexte persistant.
Fermeture de la boucle
- Une compétence learn-signals traduit les constats de production, les éléments de durcissement des contrôles et les hypothèses invalidées en nouveaux tickets de backlog pour 1 — Triage, garantissant que l’usine apprend en continu.
Consultez le guide Learn de coding-pal.
Jalon de sortie
La boucle est bouclée lorsqu’une sortie de l’étape Learn est devenue un nouveau ticket de backlog dans 1 — Triage.