Les neuf pratiques de validation. Un cadre méthodologique pour que l'erreur devienne coûteuse à cacher et évidente à repérer.
Retour sur l'atelier de Xavier Blary et Nicolas Bouillon à Agile en Seine & IA 2026.
« L'IA a tenu sa promesse… C'est bien ça le problème. » C'est sur ce paradoxe que Xavier Blary, AI Lead, et Nicolas Bouillon, Business Analyst et chef de projet chez Alenia, ont ouvert leur atelier du 22 septembre à Agile en Seine. Leur question, volontairement inconfortable : quand l'IA produit, qui contrôle ? Autrement dit, que devient la qualité, du code comme des documents, quand produire ne coûte presque plus rien ?
L'IA rédige, analyse, code et synthétise en quelques secondes ce qui prenait hier des heures. Et pourtant, sur le terrain, l'enthousiasme laisse souvent place à une fatigue diffuse. Le travail n'a pas disparu, il s'est déplacé : un peu vers l'amont, dans le cadrage de la demande, et surtout vers l'aval, dans la vérification de ce qui revient.
Le premier sondage de la séance demandait à la salle son plus gros fail avec l'IA. Les options proposées, beaucoup les ont reconnues :
Les chiffres confirment ce ressenti. Selon Graphite, environ un nouvel article en ligne sur deux est désormais généré par l'IA, une proportion stable depuis début 2025. Côté code, GitClear mesure que le refactoring est passé de 21 % des lignes modifiées en 2022 à 3,8 % en 2026 : on produit davantage, on consolide de moins en moins.
Puis la facture arrive. Dans une enquête Foxit menée auprès de 1 000 salariés et 400 dirigeants au Royaume-Uni et aux États-Unis, la vérification des productions de l'IA prend 4 h 20 par semaine aux dirigeants et 3 h 50 aux collaborateurs. Une fois ce temps déduit, le gain net tombe à 16 minutes par semaine pour les premiers, et devient une perte de 14 minutes pour les seconds.
Ce temps de relecture est le grand angle mort de la révolution générative : rarement prévu dans nos rituels, rarement outillé, presque jamais attribué à un rôle. Foxit parle de « fardeau de vérification ». L'atelier préfère parler de dette. Comme la dette technique, elle ne se voit pas tout de suite, elle grossit tant que personne ne la rembourse, et quelqu'un finit toujours par en payer les intérêts. Après la dette technique, voici la dette de validation.
Pourquoi cette dette grossit-elle si vite ? L'hypothèse de l'atelier : nos difficultés viennent moins de la technologie elle-même que de la façon dont nous l'intégrons au travail. Nous traitons l'IA comme n'importe quel logiciel.
Depuis des décennies, nous sommes habitués à manipuler des outils. Or un outil classique est déterministe. Un compilateur ou un tableur Excel ne vous ment pas pour vous faire plaisir. Un modèle génératif, si. Par sa nature probabiliste, il ressemble davantage à un nouveau membre de l'équipe : un collaborateur très rapide, qui a lu toute la documentation en une nuit, mais qui n'a aucune expérience du métier et reste aussi sûr de lui quand il se trompe.
Si ce collègue vous tendait son travail, le mettriez-vous en production sans le relire ? Le laisseriez-vous fixer lui-même ses critères de réussite ? Évidemment non. Vous lui donneriez un cadre, vous l'accompagneriez : bref, vous le manageriez. Vu sous cet angle, le défi n'est plus seulement technologique. Il devient managérial et organisationnel : comment construit-on ces équipes hybrides ?
La métaphore a pourtant ses limites :
L'IA doit donc être managée comme un collaborateur, mais contrôlée comme un outil. Le cadre de travail relève du management; le contrôle de l'assurance-qualité.
Les trois retours d'expérience présentés dessinent trois profils de ce nouveau collègue cybernétique. Chacun correspond à un piège (la confusion, l'illusion, l'omission) et appelle trois pratiques, soit neuf au total.
La promesse initiale était séduisante : confier tout le dossier du projet à l'IA (comptes rendus, spécifications, mails) pour se doter d'une mémoire infaillible. Le piège ? Le volume et le temps. Les fichiers vieillissent, des décisions s'annulent, d'autres se contredisent.
Donnez à l'IA les spécifications de la V1 et les comptes rendus de la V3 : elle en tirera une synthèse impeccable de choses contradictoires. Là où un collègue humain viendrait lever l'ambiguïté, l'IA lisse la réalité. Elle s'appuie sur des informations périmées, sans que le ton de sa réponse trahisse le moindre doute.
L'antidote : structurer l'environnement. On ne laisse pas un nouveau collaborateur fouiller seul dans un Drive désorganisé : on lui donne des clés de lecture.
Pour vaincre la page blanche, une équipe demande à l'IA d'amorcer un dictionnaire de données d'entreprise que les experts métier rechignaient à rédiger. En une nuit, elle livre un résultat très convaincant : tout semble logique, le jargon est maîtrisé. Cela agit comme un anesthésiant sur l'esprit critique, car la qualité de la forme décourage la relecture du fond.
Quelques semaines plus tard, les erreurs remontent : environ une définition sur quatre est fausse. Et pour le client, les erreurs de l'IA sont devenues celles de l'équipe. C'est le piège de l'illusion : on se laisse berner par l'assurance de la machine.
L'antidote : se rappeler que l'IA ne produit jamais un livrable, mais un brouillon.
L'IA génère le code d'une fonctionnalité, puis rédige elle-même les tests associés. Tout passe au vert. Mais en production, c'est l'incident : la machine a oublié le cas limite que personne n'avait pensé à expliciter.
Le code ressemblait pourtant à celui d'un ingénieur senior, moins les trois lignes que ce senior aurait ajoutées parce qu'il a déjà croisé ce bug. Du code faux plante à la compilation ; du code partiel passe inaperçu. En rédigeant ses propres tests, l'IA s'est faite juge et partie : un bon élève qui corrige sa propre copie.
L'antidote : séparer la conception de l'exécution. La criticité se déplace vers l'amont et vers l'assurance qualité.
Parler d'équipe hybride oblige aussi à revoir un usage très solitaire. Chacun se construit sa base de connaissances personnelle pour contextualiser ses prompts. Tant qu'elle reste individuelle, cette pratique entretient le piège de la confusion : chacun garde son contexte et sa version des règles. Et les outils de RAG mis à disposition sont souvent pensés pour l'individu plutôt que pour une équipe ou un projet.
Les fenêtres de contexte des modèles sont désormais assez grandes pour travailler directement à partir d'un répertoire d'équipe (SharePoint, wiki). Partagé, doté d'un propriétaire et fermé à ce qui n'a pas été vérifié, ce répertoire devient la mémoire de l'équipe. L'IA peut alors y tenir un rôle essentiel et pourtant presque toujours absent des équipes projet : celui de documentaliste, qui trouve, trie, analyse et confronte les sources pour que l'équipe ait rapidement une réponse précise à ses questions.
Nous avons dépassé la phase d'émerveillement : l'IA produit, c'est acquis. L'enjeu est désormais d'adapter nos façons de travailler à ce nouveau volume. Alenia a développé neuf pratiques pour le faire.
Elles n'ont rien de spectaculaire, juste du bon sens que nous aurions tous appliqué dès le départ si nous n'avions pas été émerveillés par ce nouvel outil. Elles relèvent de la clarté des rôles et de l'hygiène d'équipe plus que de la prouesse technique. Plusieurs sont d'ailleurs de vieilles connaissances des agilistes (TDD, BDD, critères d'acceptation), qui passent du statut de bonne pratique à celui de condition nécessaire.
Inutile de tout déployer d'un coup. On peut commencer par une seule règle lundi prochain : on ne présente pas un document généré par IA comme le sien. Et si vous utilisez l'IA pour s'auto-valider alors vous ne validez rien, vous vous créez un alibi.
L'IA ne supprime pas le travail : elle le déplace de l'exécution vers le cadrage et la validation. Les organisations qui en tireront le meilleur ne seront pas forcément celles qui ont le modèle le plus puissant. Ce seront celles qui auront appris à manager leurs équipes hybrides, et à traiter la dette de validation comme la dette technique : visible, mesurée et remboursée régulièrement.
Merci à toutes celles et ceux qui ont participé aux échanges.
