La revue de décision IA : le rituel Agile qui manque aux équipes

La revue de sprint semblait très bien se passer

L'équipe a démontré une fonctionnalité utile, le backlog a avancé et les parties prenantes ont vu des stories terminées. Selon les signaux habituels, le sprint était réussi.

Pourtant, une recommandation IA avait modifié une priorité, le support corrigeait des cas atypiques et le coût du workflow avait augmenté. Le système de décision avait changé sans que la compréhension commune de l'équipe ne suive.

Une revue de sprint peut rendre visible ce qui a été construit sans montrer comment une recommandation, une classification ou une action automatisée a modifié un choix. Les conséquences ressortent plus tard, lors d'une escalade, d'une surprise budgétaire ou d'un contournement de l'outil.

J'appelle le rituel manquant une revue de décision IA : une conversation courte, fondée sur des preuves, à propos d'une décision réelle qu'un système d'IA a influencée pendant le sprint.

Ce qui est un fait, ce qui est une interprétation

Cette distinction compte, car les discussions sur l'IA les mélangent souvent. Un journal peut montrer qu'une réponse a été acceptée, modifiée ou rejetée. Une évaluation donne un résultat sur un jeu de tests défini. La télémétrie indique une latence, un volume ou une dépense. Ce sont des faits observables, mais ils dépendent de la qualité et de la couverture de l'instrumentation.

L'analyse vient ensuite. Davantage de corrections après un changement de prompt peut indiquer une baisse d'utilité, mais les cas ont peut-être gagné en complexité ou le suivi a changé. Une revue solide dit : « nous avons observé », « nous pensons », « nous devons tester ».

Enfin, l'équipe décide de conserver, de protéger, de limiter, de réévaluer ou d'arrêter. Ce jugement doit avoir un responsable, une justification et une date de réexamen.

Le Scrum Guide(lien externe, nouvel onglet) présente la Sprint Review comme une séance pour inspecter le résultat et adapter la suite. La revue IA rend lisible une entrée manquante sans créer une conformité parallèle.

Pourquoi les cérémonies existantes ne suffisent pas toujours

Les rituels existants peuvent accueillir une question liée à l'IA, mais aucun ne reconstitue de façon fiable une décision qu'elle a influencée. Une démo privilégie le chemin heureux ; une rétrospective peut laisser des impressions sans le cas, la référence et le responsable nécessaires pour agir.

La revue de décision adopte une unité d'attention plus étroite : une décision, un workflow et une période. Par exemple : « Pendant ce sprint, la recommandation de catégorie de l'assistant de tri du support a-t-elle influencé la priorité donnée à un ticket client ? » Cette question peut recevoir une réponse à partir d'un petit ensemble de cas. Elle impose aussi une frontière utile : le système a-t-il conseillé une personne, préparé un brouillon ou exécuté une action sans validation immédiate ? La gouvernance nécessaire n'est pas la même dans ces trois situations.

Le workflow opérationnel en quinze minutes

Examinez un workflow par sprint lorsqu'il est nouveau, sensiblement modifié, important ou porteur d'un signal inhabituel. Avant la réunion, le Product Owner ou le responsable de livraison prépare une fiche : question, rôle du système, période et paquet de preuves minimal. Ajoutez des cas représentatifs, le résultat de l'évaluation concernée, les corrections humaines et un signal de coût, latence, incident ou retour client. L'observabilité rend la production inspectable ; les évals rendent testable un niveau de qualité choisi.

Répartissez les quinze minutes en quatre mouvements :

1. Énoncez la décision et le niveau d'autonomie. Nommez ce que le système a influencé, s'il conseille ou agit, et la personne responsable du résultat.
2. Examinez les preuves. Regardez les cas et les mesures préparés. Séparez observations et interprétations, puis nommez ce qui manque.
3. Testez l'exception. Étudiez une correction, une escalade ou un cas limite. Pourquoi une personne est-elle intervenue, et le garde-fou la détecterait-il encore ?
4. Consignez une adaptation. Attribuez une action, un responsable et une date : enrichir les évals, modifier un seuil, orienter des cas vers un humain, alerter sur la dépense ou suspendre la livraison.

La sortie est une entrée dans un journal de décision, pas un diaporama : workflow et date ; décision ; preuves ; lacunes ; adaptation et responsable ; date de revue. Conservez les liens exacts pour que le compromis reste reconstituable.

Un exemple concret sans le faire passer pour une preuve

Imaginons un assistant qui prépare des réponses à des demandes d'accès à un compte. L'équipe examine des brouillons acceptés, fortement modifiés et escaladés, puis observe davantage de corrections pour les comptes d'entreprise partagés. Son jeu d'évaluation ne contient aucun cas de ce type. Les faits sont les corrections et l'absence de couverture ; l'analyse est une possible fragilité face à l'ambiguïté sur le propriétaire. L'échantillon est peut-être petit et les corrections peuvent refléter une préférence rédactionnelle. L'équipe n'étiquette donc pas le modèle comme dangereux : elle ajoute des cas représentatifs aux évals, oriente les demandes ambiguës vers un humain et vérifie au sprint suivant. Les corrections répétées peuvent aussi révéler une politique floue, une interface médiocre ou une tâche à ne pas automatiser.

Qualité, livraison, coût et risque appellent des signaux différents

Il n'existe pas de score universel de qualité IA. Pour un assistant de recherche, l'ancrage dans les sources peut compter ; pour un classifieur, les formes d'erreur ; pour un agent qui modifie des données, l'autorisation et la réversibilité. Définissez les mesures à partir des conséquences du workflow, puis explicitez leurs limites.

Les indicateurs de livraison décrivent le système de livraison ; ils ne prouvent pas qu'une sortie IA est utile ou sûre. DORA aide à améliorer la livraison, sans être un score de qualité de modèle. Suivez, lorsque c'est possible, le coût par résultat accompli : une facture basse peut masquer une réponse moins bonne ou une réparation humaine coûteuse. Si les signaux de coût, qualité et livraison divergent, instrumentez avant d'étendre.

Le risque est spécifique lui aussi. Données, permissions, effet discriminatoire, sécurité, obligations réglementaires et résilience ne tiennent pas dans un seul feu tricolore. L'AI Act(lien externe, nouvel onglet) est fondé sur les risques, mais son applicabilité dépend du contexte. Sollicitez les spécialistes concernés : cette revue n'est ni un conseil juridique ni un substitut aux contrôles formels.

Contre-arguments et limites

Les équipes ont déjà trop de réunions : une revue qui ne modifie aucune décision est du gaspillage. Gardez-la courte, centrée sur un cas et déclenchée par un workflow important. Sans preuves, améliorez l'instrumentation au lieu de débattre d'opinions.

La mesure peut aussi devenir théâtrale : tableaux de bord et évaluation étroite peuvent manquer un préjudice en production. Rendez le périmètre visible, inspectez les exceptions, cherchez le retour des personnes concernées et préservez les voies de correction. Ne centralisez pas non plus chaque changement de prompt. Les contrôles doivent suivre le niveau d'autonomie : un assistant de notes internes mérite moins qu'un système qui décide d'une éligibilité ou modifie des données client. Escaladez selon les conséquences.

Mon point de vue : préserver la responsabilité humaine de l'adaptation

Je ne pense pas que l'Agile ait besoin d'un grand cadre supplémentaire pour l'IA. Il lui faut une manière disciplinée de voir où l'automatisation a modifié une décision avant que l'organisation ne normalise ce changement. La question la plus utile n'est pas « le modèle a-t-il bien performé ? », mais « qu'avons-nous laissé ce système influencer, et quelle preuve justifie le prochain niveau de confiance ? »

Cette question est compatible avec la préférence de l'Agile pour le feedback et l'adaptation. C'est aussi pourquoi le Manifeste Agile ne suffit pas à lui seul lorsque des systèmes agissent entre deux cérémonies : ses valeurs restent utiles, mais les équipes ont besoin de pratiques concrètes pour les décisions prises à la vitesse des machines.

Après le prochain sprint, choisissez un workflow assisté par IA et consignez une seule adaptation à partir d'un cas, d'un signal de qualité, d'une correction humaine et d'un signal de coût, de risque ou de livraison. Relisez le journal après trois revues : il dira si l'équipe apprend ou se limite à rendre compte.

Sources

• The Scrum Guide (2020)(lien externe, nouvel onglet) - guide de référence de Scrum, notamment sur la Sprint Review.
• Manifesto for Agile Software Development(lien externe, nouvel onglet) - texte original des valeurs et principes Agile.
• NIST AI Risk Management Framework 1.0(lien externe, nouvel onglet) - cadre du National Institute of Standards and Technology des États-Unis pour gérer les risques IA.
• NIST AI RMF Playbook(lien externe, nouvel onglet) - guide pratique des fonctions Govern, Map, Measure et Manage du cadre.
• DORA: Accelerate State of DevOps Report 2024(lien externe, nouvel onglet) - recherche sur la livraison logicielle et la performance opérationnelle.
• Regulation (EU) 2024/1689 (AI Act)(lien externe, nouvel onglet) - texte officiel de l'Union européenne sur l'AI Act.