Dev With AI 2026 : ce qui change dans le travail des développeurs

Le 12 octobre 2026, la première conférence Dev With AI réunissait des développeuses et développeurs au Forum des Images, à Paris. J’y présentais mon talk sur le parcours du code au merge. Le reste de la journée élargissait la question : comment préparer le travail des agents, vérifier leurs résultats et construire un produit dont quelqu’un a besoin ?

J’ai rassemblé les interventions dans un compte rendu illustré, accessible ci-dessus en lecture et en téléchargement. Cette page en propose une synthèse. Le dossier complet conserve les détails par talk, les différences entre les approches, les photos, les profils des intervenants et les ressources pour poursuivre.

Mise à jour du 16 octobre 2026. Le dossier intègre les 12 supports désormais disponibles dans le programme officiel. Les ajouts précisent les mesures de Dorra, la grille de Conversation Review, les protocoles de Jean-Louis et les mécanismes présentés par Katia. Les slides de Brevo et de Philippe Prados restent absentes de la page consultée. Les résultats chiffrés sont attribués aux intervenants, sans réplication indépendante.

TL;DR

Sujet	Ce que je retiens de la journée
Review et intégration	Générer davantage de code peut augmenter le travail en attente. Les tests, les décisions et la coordination doivent suivre.
Contexte métier	Cartographier les systèmes et reconstruire les règles du legacy demande un travail que les conventions de code ne couvrent pas.
Choix du workflow	Un skill disponible peut ne jamais être exécuté. Une couche supplémentaire mérite d’être comparée à un parcours plus simple.
Qualité des contrôles	Un test vert, une review et un évaluateur peuvent manquer une erreur. Leur capacité à détecter des défauts connus se vérifie aussi.
Produit	Les retours utilisateurs, la distribution et la vente continuent d’occuper les personnes qui développent avec l’IA.

La review et la livraison absorbent une partie du travail gagné

Chez Brevo, Mickaël Arias et Maxence Bourquin décrivent le passage d’une Feature Factory à une plateforme de collaboration. Une contribution peut traverser plusieurs dépôts et équipes. Pour la rendre possible, il faut partager la connaissance des systèmes, leurs dépendances et les personnes capables d’arbitrer. Leurs agents préparent aussi la review, en distinguant les corrections proposées des décisions qui reviennent au mainteneur.

Leur retour garde une limite très concrète : ouvrir les contributions augmente la demande de review. Un contexte absent ou périmé peut également conduire l’agent à inventer des composants. Au moment du talk, ils indiquent conserver une revue humaine systématique ; l’allègement futur de certaines reviews reste une intention.

Mon intervention traite la suite de cette chaîne : contrôles locaux, PR compréhensible, consolidation des retours et corrections avec une condition d’arrêt. Un reviewer peut trouver un défaut tout en proposant le mauvais correctif. Avant de l’appliquer, je veux comprendre le comportement attendu et vérifier que la correction le préserve. Le dossier reprend ces points ; le guide de mon talk, Du code au merge développe le raisonnement et ses exemples.

Marek Kalnik ajoute une autre matière à relire avec la Conversation Review. Le diff ne dit pas tout du cadrage, du contexte transmis ni des décisions prises pendant l’échange avec l’agent. Son exemple montre une demande de stratégie technique qui dérive vers une implémentation. Revenir à la conversation permet de repérer ce décalage, puis de corriger une pratique ou une instruction partagée. Cette lecture complète la validation du code.

Le contexte métier se reconstruit avec les personnes qui le connaissent

Les talks d’Alexandre Jeambrun et Saif Jerbi consacrent une part du travail à retrouver ce que le logiciel existant doit faire. Les règles sont dispersées entre code, traitements planifiés, configurations et données historiques. Avant de demander une réécriture, ils reconstruisent une documentation et la confrontent aux experts métier.

Alexandre décrit une chaîne de modernisation organisée par domaines et cas d’usage. La génération vient après les spécifications, l’architecture et les contrats d’entrée et de sortie. Il combine des microtâches avec des limites de travail en cours pour éviter que les changements parallèles ne s’accumulent au merge. L’analyse d’impact à l’échelle du système reste en travail dans son récit ; il ne présente pas la refonte complète comme livrée.

Saif utilise les résultats historiques pour comparer les comportements. Il raconte aussi les limites d’un premier échantillon : élargir les périodes examinées fait apparaître des cas absents de la documentation initiale. La validation des experts et l’accès au code ou aux configurations autorisés restent nécessaires lorsqu’une information manque.

Ces retours donnent un contenu précis au mot « contexte ». Une liste de conventions peut aider un agent à écrire dans le style du dépôt. Elle ne lui apprend pas, à elle seule, pourquoi une règle existe ou si le métier souhaite encore la conserver. Le guide Une seule source configure Claude Code et Codex traite une question complémentaire : distribuer ce contexte sans confondre génération, installation et comportement vérifié.

Les tests et les évaluateurs ont besoin de leurs propres vérifications

Dorra Bartaguiz part d’un exercice dont les règles comprennent des dates et des cas limites. L’agent annonce une couverture qui ne correspond pas à sa mesure ; elle trouve ensuite des défauts dans le code et dans les tests. Le mutation testing lui sert à vérifier si les assertions détectent une modification volontairement incorrecte du comportement.

Elle reprend le travail en explicitant le vocabulaire métier, les exemples et la stratégie de tests, puis en avançant par petits pas avec le TDD. Je retiens surtout la place du comportement attendu dans ce parcours. Ajouter des tests dont les résultats attendus sont faux peut donner une impression de sécurité sans protéger la bonne règle.

Jean-Louis Rigau examine le même problème au niveau du workflow. Son cas porte sur une bibliothèque de clauses contractuelles, avec une exigence d’absence de doublon lors d’une nouvelle tentative. Il compare des configurations d’agent, de skill et de review, puis examine les erreurs de l’évaluateur lui-même.

Le support précise désormais le protocole r07a : 3 modèles × 4 workflows × 5 répétitions, soit 60 résultats. Une autre étude, r08, compte 90 essais et doit rester séparée. La comparaison des évaluateurs v4 et v5 porte sur les mêmes candidats, sans nouvelle génération : elle détecte un historique bloqué après une erreur de chargement et change les verdicts. La réussite de la tâche, le respect du workflow et le coût sont trois mesures distinctes ; les petits effectifs limitent la généralisation.

Chaque couche autour du modèle mérite d’être mise à l’épreuve

Guillaume Laforge présente Antigravity à travers la délégation et l’inspection du travail : plans à commenter, changements à revoir et artefacts de vérification. Les surfaces et fonctions décrites restent celles de sa démonstration. Son conseil d’expérimenter sur un projet et de demander des explications relie aussi l’usage de l’agent à l’apprentissage du développeur.

Tugdual Grall et Xavier Noya invitent à réexaminer les instructions et les skills à mesure que les modèles évoluent. Xavier raconte des essais de frameworks de spécification où les lectures de Markdown, validations et grosses PR finissent par produire des acceptations mécaniques. La spécification garde son intérêt, mais chaque étape devrait aider à décider ou à vérifier quelque chose. Un clic de validation peut devenir une habitude assez éloignée d’une lecture attentive.

Philippe Prados examine le coût des cycles, du contexte et des opérations d’outils. Son intervention distingue le choix du modèle, l’effort de réflexion et la longueur de la réponse visible. Elle donne aussi des pistes sur le cache, la sélection des outils et la réduction des recherches répétées. Le facteur de réduction annoncé dans le titre de son talk reste un objectif du programme, sans économie de cet ordre validée par ce compte rendu.

Le retour de Patrick Szymkowiak sur RTK prolonge la discussion avec la compression des sorties de commandes et le passage aux besoins d’équipe : attribution des coûts, politiques partagées et distribution des pratiques. Réduire le texte transmis au modèle traite une partie de la consommation. Pour savoir ce que cela change au travail accepté, il faut aussi compter les échecs, les reprises et les interventions humaines. Le rapport Back Market et OpenRouter fournit un autre retour d’équipe sur le budget par personne et le choix des fournisseurs, distinct des talks de cette conférence.

Les retours produit conservent leurs différences

Bathilde Rocchia compare ses projets mobiles et décrit un déplacement vers davantage de témoignages et de retours utilisateur avant l’implémentation. Elle utilise aussi l’IA pour des visuels et le site, tout en gardant des retouches manuelles. Son retour sur les publications automatiques souligne une limite personnelle : elle peut produire davantage tout en ayant le sentiment de perdre la maîtrise de son projet.

Rémi Lakmeche présente HorseBrokers, une application pour les courtiers en chevaux de sport. Il s’appuie sur BMAD et Claude Code pour développer sur une stack qu’il ne maîtrisait pas auparavant, tout en gardant le brief et les arbitrages. Il raconte les contrôles qu’il a dû ajouter autour de ce parcours, puis le travail de prospection pour obtenir des essais et vendre.

Son usage de BMAD apporte une nuance aux critiques de Xavier. L’un décrit un parcours solo qu’il trouve utile ; l’autre rapporte les limites rencontrées dans ses essais en équipe. Les deux retours ne suffisent pas à établir une recommandation générale sur la méthode. De même, l’usine décrite par Alexandre répond à un volume et à une organisation précis.

Katia Gil Guzman décrit désormais trois mécanismes documentés par son support : les extensions d’interface, WebMCP pour exposer des actions de l’application à l’agent, et les annotations pour relier une sélection à l’intention de l’utilisateur. Aisle, ArchMorph et JupyterLite illustrent le partage de l’état de l’application entre humains et agents. Le dossier rapporte ces exemples sans certifier la disponibilité actuelle des API.

Cinq essais à choisir selon le problème rencontré

Ces pistes sont mes propositions de suivi, sans engagement attribué aux intervenants. Je commencerais par celle qui correspond à une difficulté observable sur un changement récent.

1. Définir la réussite avant l’essai. Choisir un comportement métier et ses cas limites, puis conserver les mêmes critères pendant la comparaison.
2. Retirer une couche pour la comparer. Rejouer des tâches comparables avec et sans un skill ou une review supplémentaire, en conservant ce qui a réellement tourné, les échecs et les interventions.
3. Relire une conversation avec un collègue. Retrouver l’intention initiale, une dérive de périmètre ou une correction répétée, puis choisir une cause à traiter.
4. Éprouver un contrôle. Soumettre un défaut connu et une variante correcte aux tests ou à l’évaluateur. Conserver les verdicts séparément si l’instrument change.
5. Vérifier ce qui arrive après la génération. Comparer les comportements historiques pour un legacy, obtenir des retours utilisateur pour un produit, et suivre l’attente de review ainsi que les reprises.

Pour un exemple distinct de comparaison ayant conduit à écarter les configurations testées, le dossier Jev et les essais locaux Laya conserve les résultats et leurs limites. Ces essais portent sur Laya ; ils ne mesurent pas l’API Jev.

Le compte rendu complet permet de revenir aux interventions avant de choisir. Il contient aussi le glossaire, les photos, les profils des intervenants, la présentation du comité de contenu et les formations annoncées par Greg. Les calendriers de formation sont à vérifier dans le catalogue Dev With AI.

Merci à Greg Lhotellier, ainsi qu’au comité de contenu, Marek Kalnik, Laetitia Lanfranchi et Arthur Magne, pour cette première édition. Si vous avez mis à l’épreuve l’une de ces pratiques, je serais curieux de connaître la tâche choisie, le résultat et ce qui vous a fait changer d’avis.