TL;DR : Depuis janvier 2026 et la dernière vague de modèles Anthropic, le workflow de mon équipe s'est réécrit tout seul — et le métier n'a jamais été aussi agréable. Un panel de sous-agents avec personas débat désormais de chaque merge request et de chaque issue qui arrive, et identifie des blocages auxquels on n'aurait jamais pensé, même à plusieurs. Les réunions s'enregistrent toutes seules — magnétophone du téléphone ou transcript Teams — et un skill transforme l'audio en compte rendu structuré, puis ouvre des issues GitHub ou GitLab assignées aux bonnes personnes. Les corvées techniques, les comptes rendus, les mails de relance — disparus. Ce qu'on fait toute la journée maintenant, c'est ce pour quoi on est venu : du métier, du produit, du business. Le travail qu'on a toujours voulu faire est enfin celui qu'on fait.
En mars j'ai écrit que le SDLC est mort. Le lendemain, j'ai défendu l'idée que coder n'a jamais été le métier. Six mois après le début 2026, je veux écrire le troisième panneau de ce triptyque — pas comme un manifeste cette fois, juste un retour de terrain. À quoi ressemble vraiment une équipe IA-native un mardi ? La mienne. Voici ce qu'elle fait.
Personne n'a décidé tout ça. Pas de kick-off, pas de PowerPoint, pas de "stratégie IA". Les derniers modèles Anthropic sont arrivés en janvier, on a bricolé, un truc a tenu, puis un autre a tenu, et quatre mois plus tard le workflow ne ressemble plus du tout à celui de décembre. L'IA n'a remplacé personne dans mon équipe. Elle a juste absorbé silencieusement les parties du métier qu'on détestait.
Le panel de review que personne n'a demandé
La revue de code, c'était le goulot d'étranglement. Une PR attendait deux jours. Puis un senior la relisait, ratait la moitié de ce qui comptait (c'était vendredi), validait. Maintenant elle passe par ce que j'appelle le panel de review.
Quand une merge request est ouverte, un skill dédié se déclenche. Il récupère le diff, le ticket lié, le contexte architectural. Puis il convoque un petit conseil de sous-agents avec personas — un reviewer sécurité, un expert métier, un fanatique des perfs, un junior qui joue l'avocat du diable — et il les laisse débattre. Ils débattent vraiment. Le transcript est brutal, souvent plus rigoureux que ce que trois ingénieurs seniors produiraient dans une pièce. Au moment où un humain regarde la PR, l'analyse est structurée, les blocages sont nommés, et la moitié du temps le développeur a déjà corrigé en commit suivant.
"Le panel ne remplace pas la revue. Il retire le bruit avant la revue."
Ce qui m'a le plus surpris, ce n'est pas la vitesse. C'est la profondeur. Les agents attrapent ce qu'on n'attrape pas — le cas limite auquel personne n'avait pensé, la mauvaise odeur architecturale planquée trois couches plus bas, le contrat qui s'est silencieusement cassé. Trois ingénieurs seniors dans une pièce auraient dit "ça me semble bon" et seraient passés à autre chose. Le panel n'a pas de vendredi après-midi.
On utilise le même panel sur les issues entrantes. Chaque issue qui atterrit dans notre backlog passe par lui avant le tri. Le résultat est une analyse structurée — ce qui est vraiment demandé, ce qui manque, les blocages que ça implique, ce que ça touche dans le code. C'est le genre d'analyse qu'un Tech Lead ferait un bon jour, sauf que c'est tous les jours, sur toutes les issues, en deux minutes. La réunion de tri qui prenait une heure en prend dix parce que tout le monde arrive avec les notes du panel.
La qualité a monté. Personne dans l'équipe n'a eu besoin d'être convaincu. Ça marche, et une fois que tu as vu un panel d'agents démolir ta PR, tu ne reviens plus en arrière.
Ce schéma de panel adversarial n'est pas propre à la revue de code. Le skill grill-me de Matt Pocock applique la même idée à la pensée brute — un agent qui te cuisine sur ton raisonnement jusqu'à ce que les zones fragiles remontent. J'en garde un actif en parallèle pour les arbitrages produit, les choix d'architecture, les idées à moitié formées avec lesquelles j'aurais sinon débarqué en réunion. Ça fait mouche, à chaque fois. Même remède, autre patient.
Les skills qui font tourner tout ça — meeting (douze personas nommés, trois rounds : positions, débat, convergence), fast-meeting, issue-review, code-review, meeting-report pour les transcripts Teams, grill-me et quelques dizaines d'autres — sont open source dans notre repo hexagone-foundation-skills. Des personas spécialisés santé, finance et juridique sont convoqués à la demande quand le sujet l'exige.
La réunion qui s'enregistre toute seule
Il y a presque deux mois, autre chose s'est installé. Les réunions ont commencé à s'enregistrer toutes seules.
En présentiel, sur le téléphone — oui, un téléphone au milieu de la table, qui enregistre, transcrit en local. C'est devenu un réflexe — pour moi en premier, et puis pour d'autres dans l'équipe — comme amener un cahier en réunion l'était avant. En distanciel, le transcript Teams existe déjà. Dans les deux cas, à la fin de la réunion, il y a un transcript.
On passe le transcript dans un skill qui génère un compte rendu structuré. Les sujets traités, les points d'intérêt, les blocages, les décisions prises et — c'est cette partie qui a vraiment imposé l'outil — les actions assignées à chaque personne. Avec les noms. Le genre de compte rendu qu'on passait quarante-cinq minutes à écrire le lendemain matin, sauf que là c'est fait avant qu'on ait quitté la pièce et personne n'oublie l'action qu'on lui a confiée.
Puis la partie magique. La même chaîne peut prendre ces actions et les transformer en issues — assignées aux bonnes personnes, dans le bon projet, via la CLI GitHub ou GitLab. La réunion se termine. Les issues sont ouvertes. Les responsables sont notifiés. Le Tech Lead n'a rien eu à faire à part assister.
"Le mail de relance de quarante-cinq minutes que j'écrivais à 23h n'existe plus. Le travail qu'il décrivait est déjà dans le backlog avant que la réunion ne se termine."
La même chaîne maintient les roadmaps à jour. Daily, weekly — l'agent lit le compte rendu, met à jour les roadmaps des projets que je maintiens, déplace ce qui a été livré, fait remonter ce qui a glissé, signale les nouvelles dépendances. La roadmap arrête d'être un document que je redoutais de mettre à jour le vendredi après-midi pour devenir un artefact vivant qui reflète ce qui vient d'être dit. Tout le monde — équipe, PO, parties prenantes — voit la même chose, synchronisé, sans que personne n'ait à fusionner cinq versions le lundi matin.
Je veux être honnête sur ce qui est dur. Tous les transcripts ne sont pas propres — des prénoms mal entendus, du sarcasme indexé comme une décision, parfois l'agent assigne une action à la mauvaise personne. Donc on relit avant de publier. Le skill produit un brouillon. L'humain valide. C'est la seule cérémonie qu'on a gardée, et elle prend trente secondes.
La mémoire produit qu'on n'a jamais eue
Il y a un effet de bord de la chaîne de réunions que je n'avais pas vu venir. À partir du moment où chaque réunion devient un compte rendu structuré, ces comptes rendus arrêtent d'être des artefacts éphémères. Ils s'accumulent. Ils deviennent une histoire.
Une histoire des décisions produit. Pas la décision officielle figée dans un SharePoint — l'évolution réelle. Pourquoi on a choisi l'option B en mars. Ce qu'on a écarté. La contrainte qui est remontée en semaine 18 et a renversé la réponse. Qui a poussé quoi, et qu'est-ce qui les a fait changer d'avis.
Pour la première fois en quatorze ans d'environnement entreprise, mon équipe a un enregistrement continu et interrogeable de comment on est arrivés au produit qu'on a aujourd'hui. Pas un instantané. Une trajectoire.
Tout le monde peut l'interroger. Le PO. Le PM. Les testeurs. Les développeurs. Même le RSSI et l'équipe conformité. Ils posent une question à l'agent — "pourquoi on valide encore ce champ côté serveur alors que la spec a bougé au trimestre dernier ?" — et l'agent lit l'historique, ressort la réunion où la décision a été prise, l'arbitrage qui l'a imposée, et le standard qui la justifiait. De manière asynchrone. Aucun humain n'a eu besoin de se souvenir.
"La codebase mémorisait ce qu'était le produit. Maintenant elle mémorise pourquoi."
La knowledge base s'écrit toute seule. Décisions, débats, contraintes réglementaires, standards produit — tout finit encodé au même endroit que le code. Chaque persona du panel y lit. Chaque reviewer review aussi, implicitement, contre cette base.
L'onboarding s'est dramatiquement amélioré. Un nouvel arrivant passait avant des semaines à chasser le contexte — solliciter les seniors, fouiller des vieilles pages Confluence, assister à des réunions en observateur. Maintenant il demande à l'agent. L'agent répond à partir de l'historique réel du produit, avec les sources. Le senior est libéré de son rôle de serveur de documentation ambulant. Le nouvel arrivant est productif en jours, pas en mois.
Dans un domaine comme le nôtre — régulé, plein de standards, plein de "tu ne peux pas faire ça parce que l'article 14.3 de la directive dit…" — c'est transformatif. Les agents challengent en permanence nos choix contre les réglementations qu'on a écrites et les standards produit qu'on s'est engagés à tenir. Pas comme un audit ponctuel. Comme un bourdonnement continu, à bas bruit, du "tu es sûr que ça respecte toujours X ?" dans chaque revue de PR, chaque analyse d'issue, chaque décision d'architecture.
Ça nous évite de partir dans la mauvaise direction. Au quotidien. Ce simple fait, c'est un bonheur calme et profond que je n'avais pas anticipé.
Les tests qu'on promettait toujours d'écrire
Il y a un troisième workflow qui s'est installé. C'est peut-être celui qui me fait le plus plaisir.
Les tests de non-régression automatisés. La couverture end-to-end. La validation des règles métier. Les choses que chaque roadmap d'équipe contenait et qu'aucune roadmap n'a jamais vraiment livrées. Les tests qu'on promettait au comité sécurité. Les tests qu'on promettait à l'auditeur. Les tests qu'on se promettait à nous-mêmes trois roadmaps de suite, avant de les rétrograder discrètement en "phase 2" parce que la prochaine fonctionnalité ne pouvait pas attendre.
Pendant quatorze ans, j'ai vu les équipes dégrader leurs propres livrables exactement de la même façon. Pas par paresse — par arithmétique. Un senior écrit une fonctionnalité en trois jours. Le même senior écrirait la couverture e2e en trois jours de plus. Donc la couverture saute. À chaque fois. Le livrable part en prod avec un trou de qualité connu dont personne ne parle en COPIL.
Cette arithmétique est cassée maintenant.
Les agents génèrent la suite e2e en même temps que la fonctionnalité. Même boucle, même contexte, mêmes règles métier. Les scénarios de non-régression métier — ceux qui sortent directement de la spec, ceux qui vivent dans la tête du PO, ceux qu'un utilisateur a remontés dans un ticket il y a deux ans — sont encodés en tests, automatiquement, au moment où la fonctionnalité est construite. Pas en phase 2. Pas au Q3. Dans la même merge request.
Et le panel les review. Le persona métier vérifie que le test représente bien la règle. Le persona performance signale les scénarios qui seront lents. Le persona junior demande "et ce cas limite ?" — et le persona senior répond en code.
"On produit enfin la couverture de tests qu'on devait à nos applications depuis dix ans. C'est comme rembourser une dette que j'avais fini par considérer comme perdue."
Je veux être honnête sur l'ampleur de la chose. Le trou de qualité créé par la roadmap est la cause numéro un de la fragilité des logiciels d'entreprise. Tout le monde le sait. Personne ne le corrige, parce que la correction ne passe jamais le filtre de priorisation. Maintenant la correction n'a plus besoin de passer ce filtre — elle part avec la fonctionnalité, par défaut, parce que l'agent ne fatigue pas et n'a pas de deadline.
Les applications dont je suis responsable ont plus de couverture e2e aujourd'hui qu'après une décennie d'effort humain. Je me l'entends dire à voix haute et je continue de trouver ça absurde. Fou, c'est le bon mot.
Ce qui a changé dans l'équipe
Il serait facile de lire ça et de penser que l'équipe est devenue plus petite, plus rapide, plus individualiste. Le contraire s'est produit.
Les juniors montent en compétence plus vite. Ils arrivent en revue avec l'analyse du panel déjà en main. Ils arrivent en réunion avec le compte rendu de la précédente déjà structuré. Ils n'ont plus besoin de demander "qu'est-ce qui est important ici ?" — les agents ont déjà cadré la question. Leur énergie cognitive va au métier, pas à naviguer dans le processus.
Les seniors ont arrêté de perdre du temps en théâtre de revue. Il y a cinq ans, faire une revue de PR sérieuse voulait dire bloquer deux heures, lire chaque ligne, et rater des choses quand même. Maintenant le panel fait le premier passage. Le senior passe dix minutes sur ce qui demande vraiment du jugement — choix architecturaux, cas limites métier, les choses que l'agent ne peut pas trancher. Le temps gagné part en mentorat, en design, en livraison.
Personne ne lutte contre. C'est ce qui m'a le plus surpris. Pas de résistance. L'équipe n'a pas eu besoin d'un plan de formation ni d'un atelier conduite du changement. Ils ont essayé le panel une fois, l'ont vu attraper un vrai problème, et l'habitude s'est prise. Six mois plus tard, demander à quelqu'un de mon équipe de "reviewer sans le panel" reviendrait à lui demander de compiler à la main.
Le métier qu'on a toujours voulu faire
Voilà la partie dont personne ne parle. C'est franchement agréable.
Je n'ai pas rédigé de compte rendu de réunion depuis deux mois. Je n'ai pas formaté de mail de relance depuis mars. Je n'ai pas passé de samedi matin à me battre avec un YAML de CI ou à chasser un test instable. Les corvées techniques que je redoutais — elles n'existent plus. Les agents s'en occupent, mieux et plus vite que je ne l'ai jamais fait, et eux ne râlent pas.
Ce que je fais maintenant toute la journée, c'est le travail que je voulais vraiment faire. M'asseoir avec le PO et stress-tester un workflow clinique. Lire un retour terrain attentivement jusqu'à comprendre ce que l'utilisateur clinique voulait vraiment dire — pas juste ce que le ticket disait. Croquer un modèle métier au tableau avec deux collègues jusqu'à ce que ça fasse "clic". Lire la dernière réglementation d'interopérabilité et chercher ce que ça implique pour notre roadmap. Engueuler mon homologue Tech Lead parce qu'on modélise le mauvais concept.
Autrement dit : du métier. Le vrai problème qu'on est payés à résoudre.
"Mon agenda est désormais rempli de conversations sur le métier. Il était rempli de conversations sur le processus. Ce déplacement-là, c'est tout le métier."
Le changement n'est pas subtil. C'est ce que chaque développeur senior a toujours voulu en secret : plus de métier, plus de produit, plus d'échanges avec les gens que le logiciel sert vraiment — et moins de temps à traduire une intention en syntaxe, à se battre avec des outils de build, ou à formater un compte rendu que personne ne lira.
L'équipe le ressent. Les juniors plus que les autres. Ils sont arrivés dans le métier en s'attendant à passer des années bloqués dans la couche technique avant d'avoir le droit de penser au métier. Ils ne sont pas bloqués. Ils sont déjà dans les conversations qui comptent, avec le panel qui tient la discipline technique qu'ils n'ont pas encore acquise. Voir un alternant faire son premier vrai arbitrage métier en troisième semaine au lieu de la quatre-vingtième — ça, c'est la partie que je n'avais pas anticipée et qui me rend heureux.
Je fais ce métier depuis quatorze ans. Je ne l'ai jamais autant aimé que maintenant. Le métier a changé sous nos pieds, et la version sur laquelle on a atterri, c'est celle dont je rêvais sans oser le dire.
Ce qui reste aux humains
Je ne veux pas survendre. Beaucoup de choses sont encore les nôtres.
Décider ce qu'on construit. Aucun agent n'a la lecture politique d'un projet, la relation client, ni le contexte stratégique qui dit "on ne livre pas ça même si on peut". Ça reste un Tech Lead, un PO, quelqu'un qui connaît la salle.
Détecter quand le panel se trompe. Les agents argumentent bien. Ils se trompent aussi parfois avec aplomb. Le repérer demande de l'expertise métier — ce même jugement dont je parlais dans l'article précédent. Le panel ne remplace pas l'ingénieur. Il libère l'ingénieur pour le travail qui demande vraiment d'en être un.
Tenir l'architecture. Le panel revoit contre des contraintes qu'on a écrites. Quelqu'un doit écrire ces contraintes, les maintenir à jour, et trancher quand le système doit plier. Ça reste nous. Mauvais contexte en entrée, mauvais débat en sortie.
Parler à l'équipe. Une réunion transcrite et transformée en issues, ce n'est pas un un-à-un. Les conversations difficiles, le check moral, le "tu vas vraiment bien ?" — ça ne passe pas par une chaîne de transcript. Ça n'y passera jamais.
Que faire lundi matin
Si vous voulez retenir une chose de cet article et l'essayer cette semaine, voici l'ordre que je conseillerais :
- Commencer par le panel d'analyse d'issues. C'est le point d'entrée le plus facile. Prenez dix issues entrantes, faites-les passer par un petit conseil de sous-agents avec personas, comparez la sortie à ce que produit votre réunion de tri. Vous serez mal à l'aise. Puis convaincu.
- Ajouter le panel de revue de PR. Même idée, sur un seul repo, sur des PR volontaires d'abord. Ne l'imposez pas. Attendez que quelqu'un dise "attends, le panel a vu ça et nous on est passés à côté". C'est le moment où ça se diffuse.
- Enregistrer une réunion. Une seule. Passez le transcript dans un skill de résumé. Comparez au mail de relance que vous auriez écrit. Décidez si vous pouvez encore justifier de l'écrire à la main.
- Câbler la création d'issues en dernier. N'automatisez pas la création d'issues tant que la boucle transcript → compte rendu n'est pas fiable. Sinon vous spammez le backlog. Quand elle l'est, l'intégration CLI GitHub ou GitLab prend quinze minutes et vous fait gagner des heures par semaine.
- Garder l'étape d'approbation humaine. Des brouillons, pas du push automatique. La confiance vient en regardant l'agent avoir raison, pas en sautant la vérification.
Conclusion
J'attends toujours le moment où ça arrête d'avoir l'air magique. Il n'est pas encore venu.
On a absorbé des agents dans les revues, dans le tri, dans les réunions, dans le backlog. Rien de tout ça n'a été planifié. Chaque morceau a gagné sa place en étant manifestement meilleur que ce qu'on faisait avant. L'équipe est plus grande qu'il y a un an — les stagiaires et alternants se sont ajoutés à l'effectif — livre plus, dort mieux, râle moins. Les parties chiantes du métier ont disparu. Ce qui reste, c'est le travail pour lequel je suis venu dans cette industrie — et je n'ai pas autant aimé mes lundis depuis que je suis junior. Autant en profiter.
Le métier a changé. Le changement est bon. Moins de syntaxe, moins de cérémonie, moins de reporting — plus de métier, plus de produit, plus de conversations avec les gens pour qui on construit. Cet échange-là, je l'aurais signé sans hésiter il y a dix ans si quelqu'un me l'avait proposé.
Si vous avez lu les deux articles précédents en pensant que je faisais de la théorie — non. C'est ce que ça donne en pratique, dans une entreprise française, en mai 2026. Il y a six mois, rien de tout ça n'existait. Dans six mois, je n'ai aucune idée de ce qu'on aura absorbé d'autre. C'est la seule prévision honnête que j'ai.
Les outils sont là. Le réflexe, c'est la seule chose qu'il reste à installer.
Quelle est la réunion la plus chiante de votre semaine ? Enregistrez-la. Voyez ce qui en sort.
Lire la suite de la série : Le SDLC est mort — pourquoi le processus a toujours été du gaspillage. Coder n'a jamais été le métier — ce que devient l'ingénieur quand la couche de syntaxe disparaît. Le backlog n'a jamais été le métier — le même argument, côté produit. La doctrine se capitalise. Les modèles, non. — ce qui permet à cette équipe de survivre à un changement de modèle. Les tests passent. Il ne se passe rien. — le défaut sans symptôme, et ce qui l'attrape à la place de la lecture.