CONFÉRENCE · ÉDITION #01
Dev With AI
Ce qui change dans le travail des développeurs
Compte rendu de la conférence Dev With AI du 12 octobre 2026, au Forum des Images à Paris. Points clés des interventions, pratiques techniques et retours d’expérience pour développer avec l’IA.
Mise à jour du 16 octobre 2026 : les 12 supports disponibles dans le programme ont été examinés, avec des compléments datés dans chaque intervention. Les slides de Brevo et de Philippe Prados restent absentes de la page consultée. Les chiffres sont attribués aux intervenants, sans réplication indépendante.
Commencez par les points clés ci-dessous. Chaque talk dispose ensuite d’un TL;DR en 3 ou 4 points, puis du compte rendu complet à déplier.
Glossaire
Les définitions restent lisibles sans JavaScript.
- Conversation Review
- Revue d’une interaction humain-agent pour examiner l’intention, le contexte, les décisions, les outils et la validation.
- Évaluateur
- Dispositif qui juge une sortie selon des critères définis ; il peut lui-même produire des verdicts erronés.
- Harness
- Ensemble des outils, instructions, contrôles et mécanismes d’exécution autour du modèle pour réaliser une tâche.
Les autres termes du glossaire
- CI
- Intégration continue : exécution de contrôles automatisés sur les changements de code.
- Legacy
- Système existant dont les contraintes et connaissances doivent être comprises avant de le faire évoluer.
- MCP
- Protocole permettant à un agent d’accéder à des outils ou ressources exposés par un serveur.
- MVP
- Première version d’un produit permettant d’éprouver son usage ; sa disponibilité ne suffit pas à valider son marché.
- Mutation testing
- Introduction de modifications volontaires du programme pour vérifier que les tests détectent les défauts correspondants.
- PR / Pull request
- Proposition de changements soumise à examen avant intégration dans une branche.
- Retry
- Nouvelle tentative d’une opération. Elle doit parfois préserver l’absence de doublon, comme dans l’exemple des clauses.
- SDD / Spec-Driven Development
- Développement guidé par des spécifications explicites ; les frameworks cités organisent ce travail de façons différentes.
- SDLC
- Cycle de vie du développement logiciel, du cadrage aux étapes de réalisation, vérification et livraison.
- Skill
- Instructions ou ressources réutilisables destinées à une tâche ou un domaine ; installation et usage effectif sont distincts.
- Staging
- Environnement distinct de la production utilisé pour vérifier une version avant de l’exposer aux utilisateurs.
- TDD
- Développement guidé par les tests, avec un test qui échoue, une implémentation puis une amélioration du code.
- Token
- Unité de texte traitée par un modèle. Le nombre de tokens seul ne décrit ni le coût total ni la valeur du résultat.
- WIP / Travail en cours
- Travail commencé mais non terminé ; une limite de WIP réduit l’accumulation dans une étape du flux.
- Worktree
- Copie de travail Git associée à un dépôt, permettant de travailler sur des changements dans un dossier distinct.
Les talks en un coup d’œil
- Guillaume LaforgeDéléguer dans Antigravity tout en relisant les plans, les changements et les résultats de vérification.
- Mickaël Arias · Maxence Bourquin (Brevo)Partager la connaissance des systèmes et des responsabilités pour faciliter les contributions entre équipes.
- Dorra BartaguizÉprouver les tests générés : une couverture annoncée par l’agent ne garantit pas le comportement attendu.
- Marek KalnikRelire la conversation avec l’agent pour retrouver le cadrage, les décisions et les dérives.
- Alexandre JeambrunReconstruire et valider les règles métier du legacy avant de régénérer du code.
- Florian BruniauxRelier contrôles locaux, review et CI pour préparer une décision de merge éclairée.
- Tugdual Grall · Xavier NoyaRéévaluer instructions et skills à mesure que les modèles évoluent, sur ses propres tâches.
- Philippe PradosExaminer les tours d’agent, le contexte réutilisé et les opérations d’outils pour agir sur les coûts.
- Saif JerbiReconstruire les règles dispersées dans le code, les configurations et l’historique avant de réécrire.
- Jean-Louis RigauFixer les critères de qualité, coût et répétabilité avant de comparer les workflows.
- Bathilde RocchiaRecueillir des retours utilisateurs avant l’implémentation pour orienter les choix produit.
- Rémi LakmechePartir du problème métier pour cadrer HorseBrokers avec BMAD et Claude Code.
- Patrick SzymkowiakRelier la compression des sorties CLI de RTK aux usages et aux besoins des équipes.
- Katia Gil GuzmanExtensions, WebMCP et annotations permettent de partager l’état utile de l’application entre humains et agents.
Voir la synthèse transversale
Ce qu’il faut retenir
| À retenir | Concrètement | Interventions |
|---|---|---|
| Valider au rythme du code | La charge se déplace vers la revue, les tests, l’intégration et la coordination. Produire davantage de code ne suffit pas à livrer davantage de valeur. | Brevo · Dorra Bartaguiz · Florian Bruniaux |
| Reconstruire le contexte avant de réécrire | Règles métier, dépendances, responsabilités et décisions : reconstruire puis valider cette connaissance avant de réécrire le legacy. | Alexandre Jeambrun · Saif Jerbi |
| Mesurer l’apport du harness | Retirer les instructions devenues inutiles, mesurer le bénéfice d’un skill ou d’une review et tester l’évaluateur lui-même. | Tugdual Grall et Xavier Noya · Jean-Louis Rigau |
| Faire progresser les pratiques et le produit | Revoir les conversations avec l’IA ; comprendre les utilisateurs, choisir un produit et le vendre restent des activités à traiter. | Marek Kalnik · Bathilde Rocchia · Rémi Lakmeche |
| Réduire les cycles et sélectionner le contexte | Sélectionner le contexte, utiliser des opérations d’outils plus complètes et gérer le cache. Mesurer le bénéfice à qualité comparable. | Philippe Prados |
Table des matières
Un terme souligné en pointillés ouvre sa définition au survol, au clavier ou au toucher. Échap ou un clic ailleurs ferme la bulle.
Enseignements de la journée
Le code devient une étape d’une chaîne à piloter
Les enseignements communs et les différences d’approche entre les interventions.
La génération peut dépasser la capacité de vérification et d’intégration. Les talks rapprochent contexte métier et contrôle des résultats, tout en décrivant des degrés d’autonomie différents selon les projets.
Lire le détail
La convergence la plus nette concerne le déplacement du travail. Brevo décrit une contribution ouverte entre dépôts qui augmente la demande de review. Dorra Bartaguiz interroge la qualité des tests générés. Florian Bruniaux traite l’attente en CI, la compréhension des PR et les boucles de correction. Ces angles se complètent : le débit de génération peut dépasser la capacité de vérification et d’intégration.
La connaissance métier revient comme une matière première. Chez Brevo, elle prend la forme d’une cartographie des systèmes et de leurs responsables. Dans les 2 retours sur le legacy, elle doit être extraite du code, des configurations et des données, puis discutée avec les experts. Chez Bathilde et Rémi, elle vient aussi des utilisateurs et des contraintes commerciales. Ces connaissances ne se remplacent pas par une liste de conventions de code.
Les intervenants ne proposent pas le même degré d’autonomie. Brevo indique conserver une revue humaine systématique au moment du talk, tout en envisageant de l’alléger. Alexandre décrit une chaîne d’implémentation automatisée, avec le cadrage humain en amont. Saif conserve une validation métier de la documentation. Florian répartit l’attention humaine selon le risque du changement. Ces retours décrivent des choix situés ; il ne démontre pas qu’un régime convient à toutes les équipes.
Une seconde convergence invite à tester les outils de contrôle. Un test vert peut manquer une erreur métier ; une review peut proposer un mauvais correctif ; un évaluateur peut accepter une implémentation incorrecte. Dorra, Florian et Jean-Louis abordent chacun une partie de ce problème. Le nombre de contrôles ajoutés ne prouve donc pas leur efficacité.
Les interventions
Guillaume Laforge : déléguer, inspecter et apprendre
Présentation d’Antigravity à travers ses surfaces de travail et des exemples d’usage.
- Déléguer dans Antigravity tout en relisant les plans, les changements et les résultats de vérification.
- Organiser les tâches dans des projets et worktrees séparés pour suivre les agents.
- Demander des explications à l’agent pour apprendre de ses choix. Les fonctions montrées sont celles de la démonstration.
Lire le détail
Intitulé au programme : Antigravity, le dev agentique façon Google DeepMind. Programme officiel.
Intervenant : Guillaume Laforge · Developer Advocate @ Google. Fiche sur le site de la conférence.
Guillaume présente Antigravity comme un environnement pour gérer des projets et des conversations agentiques, avec une application de gestion des agents, un IDE, une CLI et un SDK. Il montre des projets pouvant réunir plusieurs répertoires, des worktrees pour séparer les modifications et des artefacts permettant de revoir un plan, un diff ou un parcours de vérification.
Les exemples donnent une place visible au contrôle du travail : commenter un plan, demander une révision, conserver des captures ou une vidéo de navigation, puis examiner les changements. Les automatisations récurrentes servent notamment à suivre l’évolution d’un SDK et à mettre à jour un programme de conférence. Une visualisation interactive permet d’examiner des polices destinées à un écran de pixel art.
Il décrit aussi des sous-agents spécialisés, des instructions, des hooks et des permissions. Le point à retenir pour le travail quotidien est l’articulation entre délégation et inspection des résultats. La liste des fonctions présentées reste un compte rendu de sa démonstration, pas une vérification des disponibilités, versions ou garanties de sécurité du produit.
Dans les questions finales, il conseille de choisir un projet d’expérimentation et d’utiliser l’IA pour apprendre. Il raconte avoir demandé une revue de sécurité puis des explications sur les problèmes signalés. Son exemple relie le résultat livré à une progression du développeur, à condition de prendre le temps de poser les questions.
Compléments du support, 16 octobre 2026
Le support précise les frontières d’Antigravity : le projet définit un périmètre de fichiers et de sécurité, avec des règles allow, ask et deny et un sandbox. Un plugin peut regrouper manifeste, serveurs MCP, hooks, skills, agents et règles. La boucle présentée reste Plan, Act, Verify.
Deux distinctions utiles : les extensions pour IDE apportent le panneau agent mais pas l’assistance IA dans l’éditeur décrite pour l’IDE complet ; le SDK Python est présenté comme officiel, celui pour Java comme non officiel. L’exemple de reviewer GitHub limite les capacités à la lecture, refuse le reste et impose une sortie structurée. Ce sont les capacités décrites dans le support, sans vérification de leur disponibilité actuelle.
Support officiel · Diapositives 4, 11, 25, 28, 40, 46–47.
Brevo : partager le contexte et préparer la review
Mickaël Arias et Maxence Bourquin décrivent le passage d’une Feature Factory à une plateforme de collaboration.
- Partager la connaissance des systèmes et des responsabilités pour faciliter les contributions entre équipes.
- Préparer la review avec des agents, en distinguant corrections possibles et décisions du mainteneur.
- Un contexte manquant ou périmé peut faire inventer des composants et alourdir la review.
- Au moment du talk, Brevo conserve une validation humaine systématique.
Lire le détail
Intitulé au programme : Software Factory : l'IA collaborative qui réinvente le dev chez Brevo. Programme officiel.
Intervenant : Mickaël Arias · CTO @ Brevo. Fiche sur le site de la conférence.
Intervenant : Maxence Bourquin · Engineering Manager @ Brevo. Fiche sur le site de la conférence.
Le problème décrit dépasse la vitesse d’un développeur. Une modification peut nécessiter plusieurs dépôts et l’intervention de propriétaires de code occupés ailleurs. Brevo ouvre les contributions entre équipes tout en conservant des code owners pour l’arbitrage final. Le savoir-faire devient une ressource à transmettre par des skills et des workflows.
Le premier produit, la Feature Factory, proposait un parcours de spécification et d’implémentation collaboratif. Mickaël explique les limites d’adoption : un flux trop figé, une nouvelle interface à apprendre et une couverture réduite à la création de fonctionnalités. La suite repose sur 4 briques décrites dans le talk : contexte des systèmes et de l’organisation, savoir-faire partagé, plateforme d’exécution agentique et agent d’interaction.
La démonstration de review suit un périmètre validé, compose des agents selon les changements et sépare les points à corriger des notes destinées au mainteneur. Le contributeur peut accepter une correction ou justifier un refus. Le mainteneur reçoit ensuite les éléments qui demandent son jugement, notamment les choix d’implémentation et la cohérence entre dépôts.
Les questions rendent les limites concrètes. Les intervenants reconnaissent la surcharge de review et des erreurs lorsque le contexte manque ou décrit une ancienne architecture. Maxence rapporte qu’un agent privé de son accès au contexte a inventé des composants. Maintenir la cartographie à jour reste un travail à organiser ; l’écoute de Slack et des décisions de réunions est présentée comme une piste, pas comme un dispositif déjà qualifié.
Dorra Bartaguiz : éprouver les tests et expliciter le métier
Les pratiques Craft servent à contrôler la production des agents, dès le cadrage.
- Éprouver les tests générés : une couverture annoncée par l’agent ne garantit pas le comportement attendu.
- Expliciter les règles métier, le vocabulaire et les exemples avant de reprendre le code.
- Avancer par petits pas en TDD et utiliser le mutation testing pour vérifier la force des assertions.
Lire le détail
Intitulé au programme : Quand la vélocité explose avec l'IA : place au "Harness Engineering" ! Programme officiel.
Intervenant : Dorra Bartaguiz · CTO @ Arolla. Fiche sur le site de la conférence.
Dorra part d’un kata de calcul de dates d’invitation à un dépistage, inspiré d’une mission de coaching. L’intérêt de l’exemple tient aux règles et aux cas limites : calcul de base, dates invalides, jours non ouvrés et reports. Il s’agit d’un exercice de développement décrit dans le talk, pas d’une recommandation médicale.
L’agent annonce avoir atteint la couverture demandée, mais Dorra rapporte une mesure différente et découvre des défauts dans le code comme dans les tests. Elle utilise le mutation testing : modifier volontairement le comportement du programme puis vérifier si les tests détectent l’écart. Ce contrôle permet de questionner la capacité des assertions à protéger le comportement attendu.
Elle rejoue ensuite le travail avec un parcours explicite : explorer les termes métier, découper le besoin, formuler des exemples, choisir une stratégie de tests, automatiser les scénarios puis implémenter par petits pas. Le TDD sert ici à guider et contrôler l’agent. Les connaissances auparavant transmises entre développeurs peuvent être rendues explicites dans des skills.
Le talk élargit enfin la perspective au cycle de vie du produit : stratégie et design en amont, observabilité, maintenance et retours d’usage en aval. Équiper uniquement la phase de développement risque de déplacer l’attente ailleurs. Les agents plus autonomes demandent aussi des conditions d’arrêt pour leurs boucles.
Compléments du support, 16 octobre 2026
Les slides chiffrent le décalage du kata : l’agent annonce 100 % de couverture, alors que Dorra mesure 33 % sur l’ensemble et 95 % sur le domaine. Le score de mutation présenté est de 13,82 %. Ces mesures portent sur des périmètres différents : une couverture élevée du domaine ne suffit pas à établir que les assertions détectent les défauts.
La reprise commence par le vocabulaire métier, des exemples et la décomposition, puis une stratégie de tests d’acceptation, unitaires et de bout en bout. La fin du support étend le harnais au cycle produit, de la découverte à l’exploitation. Le Loop Engineering y traite les boucles infinies et la stagnation ; la software factory combine ces contrôles avec la supervision humaine.
Support officiel · Diapositives 16, 19, 27–38, 48–58.
Marek Kalnik : revoir la conversation pour faire progresser l’équipe
La Conversation Review ajoute une lecture des décisions et du travail délégué à la revue du code.
- Relire la conversation avec l’agent pour retrouver le cadrage, les décisions et les dérives.
- Distinguer la délégation d’exécution de la discussion sur la conception : une demande de stratégie peut dériver vers l’implémentation.
- Transformer les enseignements en pratiques et instructions partagées, puis vérifier le code produit.
Lire le détail
Intitulé au programme : La Conversation Review : Le guide pour faire progresser les équipes AI-native. Programme officiel.
Intervenant : Marek Kalnik · CTO, Group Partner @ Theodo. Fiche sur le site de la conférence.
Marek décrit une perte possible de la fonction pédagogique de la code review lorsque les changements deviennent volumineux et que les développeurs acceptent des résultats difficiles à relire. Le travail de l’opérateur comprend désormais le cadrage, le contexte, les décisions et les interactions avec l’agent. Son cadre consiste à rendre ce travail discutable entre collègues.
Les points de contrôle proposés portent sur la taille et la nature de la tâche, sa réalisation, la validation, le coût, les interventions humaines et la répétabilité. Il distingue une délégation d’exécution, lorsque l’objectif est déjà clair, d’un échange de conception où les questions et les idées doivent circuler. Une conversation ne se juge donc pas au seul nombre de messages.
Son exemple montre une demande de stratégie technique qui dérive vers une implémentation. Les outils et tests exécutés ensuite ne répondent pas à eux seuls à la question initiale. Revoir la trace permet de repérer ce changement de périmètre, des recherches évitables et les décisions qui auraient dû revenir à l’humain.
La discussion débouche sur des corrections du système de travail : préciser le contexte, ajouter une compétence ciblée, améliorer un mécanisme de test ou réduire une correction répétée. Le but proposé est de faire progresser l’équipe dans sa manière de construire et de piloter les agents. La Conversation Review complète la validation du code ; elle ne prouve pas sa correction.
Compléments du support, 16 octobre 2026
La Conversation Review dispose d’une grille explicite en trois axes : Intent, pour l’approche de la tâche ; Evidence, pour ce qui justifie l’acceptation du résultat ; Control, pour le périmètre, le contexte, les outils, les permissions et les décisions qui engagent la suite. Cette grille rend la relecture plus précise qu’un simple jugement sur la qualité du prompt.
Le rituel proposé dure dix minutes : choisir une session réelle, examiner une étape qui a compté et retenir une amélioration. Le support fournit aussi le projet coding-conversation-analyzer du groupe Theodo. Les économies proposées dans l’exemple de session sont des estimations de l’analyse, pas un gain mesuré après correction.
Support officiel · Diapositives 23, 34, 39.
Alexandre Jeambrun : cadrer une usine et limiter le travail en cours
Retour sur une chaîne agentique de modernisation d’un SI ancien.
- Reconstruire et valider les règles métier du legacy avant de régénérer du code.
- Générer des unités isolées à partir de spécifications, avec des contrats d’entrée et de sortie stables.
- Limiter le travail en cours pour maîtriser l’intégration des micro-tâches.
- L’analyse d’impact à l’échelle du SI reste en chantier dans le retour présenté.
Lire le détail
Intitulé au programme : Moderniser un SI vieux de 30 ans grâce à une « Usine Agentique ». Programme officiel.
Intervenant : Alexandre Jeambrun · Senior Software Engineer @ Octo Technology. Fiche sur le site de la conférence.
Alexandre commence par la rétro-documentation puis la confrontation avec les experts métier. Une règle extraite du système peut ne plus correspondre à la règle souhaitée. La suite repose sur des domaines fonctionnels, des spécifications, une architecture et des parcours utilisateur. La génération du code vient après ce travail de définition.
La chaîne décrite comprend un coordinateur distribuant les tâches et des systèmes agentiques chargés de planifier, implémenter, revoir, corriger et suivre les pipelines. Le contexte partagé doit conserver la cohérence entre projets. Dans la review, les agents examinent les standards, la stratégie de tests et les critères de sécurité ; une passe supplémentaire vérifie que les problèmes signalés existent avant de préparer les corrections.
Un choix de conception distingue ce retour : régénérer une unité isolée à partir des spécifications plutôt que multiplier les modifications sur son code. Alexandre relie ce choix à une modularisation par cas d’usage, avec des contrats d’entrée et de sortie stables. La stabilité des contrats est une condition de l’approche décrite, pas une garantie que toute régénération reste sans impact.
Il utilise aussi le flux tiré et des limites de travail en cours. Les microtâches peuvent se paralléliser, mais le merge doit être protégé contre l’arrivée de changements concurrents. Le point de contrôle se situe donc autant dans l’organisation du flux que dans l’agent qui écrit.
Compléments du support, 16 octobre 2026
Le support donne l’échelle du SI étudié : 33 millions de lignes et 18 langages. L’architecture associe un coordinateur avec interface et API, une file de tâches, un Context Broker sémantique, des dépôts de spécifications et de composants, puis un pool d’agents. La chaîne va de la rétrodocumentation aux spécifications, au backlog, à la Definition of Ready et au plan d’implémentation, avant review, correction, build et merge.
La review combine quatre analyses parallèles : qualité du code, tests manquants, exécution des tests et sécurité/conformité. Un vérificateur indépendant relit ensuite les fichiers et les constats avant de produire le plan de correction. Les planches du tableau illustrent une limite de travail en cours de deux éléments dans la colonne À DEV. Cette valeur appartient à l’exemple ; le support ne démontre ni une limite universelle ni la livraison de toute la modernisation.
Support officiel · Diapositives 3–9, 10–21.
Florian Bruniaux : organiser les contrôles du poste au merge
Le harness relie préparation locale, review, CI et responsabilité du changement.
- Relier contrôles locaux, review et CI pour préparer une décision de merge éclairée.
- Vérifier séparément le diagnostic d’un reviewer et le correctif proposé.
- Borner les reprises avec un objectif, un budget et une condition d’arrêt.
- Le retour décrit une accélération sans mesure isolant l’effet de l’ensemble du harnais.
Lire le détail
Intitulé au programme : Coder plus vite avec l’IA, livrer mieux en équipe : du code au merge. Programme officiel.
Intervenant : Florian Bruniaux · Founding Engineer / Harness Engineer @ Méthode Aristote. Fiche sur le site de la conférence.
Guide détaillé du talk, slides et exemples : Du code au merge (français) · From code to merge (English).
Florian décrit un travail qui s’accumule entre la production de code et la livraison : PR en attente, conflits, analyse humaine, minutes de calcul et relances. Détecter tôt une erreur évite de répéter ce travail en aval. Il présente le déplacement de contrôles vers le poste du développeur, avec une contrainte matérielle et un coût à considérer.
Une PR doit pouvoir être comprise par l’humain et par les agents reviewers. Il explique avoir cherché un équilibre entre description courte, règles métier, architecture, tests et détails techniques repliables. La traçabilité du modèle, des skills et des agents sert ensuite à rejouer et améliorer le parcours.
La review combine CodeRabbit, FriendlyReviewer et un reviewer maison qui évolue vers les règles métier. Une étape rassemble les retours, rapproche les doublons et examine les contradictions. Florian insiste sur la différence entre trouver un défaut et proposer la bonne correction. Son exemple d’erreurs de document absent ou d’accès interdit montre pourquoi le correctif suggéré doit être confronté au comportement attendu.
L’attention humaine est orientée vers les changements jugés sensibles, par exemple les paiements, les droits d’accès ou les données privées. Il reconnaît que ce tri peut se tromper. Les corrections doivent avoir une condition d’arrêt : objectif atteint, budget consommé, nombre d’itérations, blocage ou désaccord. La CI doit aussi distinguer une erreur trouvée par un test d’un contrôle qui n’a pas pu s’exécuter.
Le retour sur une PR devient une matière pour corriger la cause d’une erreur répétée, ajuster le harness et rejouer le cas. Les gains et les coûts évoqués restent ceux de son expérience exposée oralement ; ce compte rendu ne démontre ni des économies réconciliées ni un gain de livraison mesuré.
Compléments du support, 16 octobre 2026
Le support rend la validation plus concrète : une modification d’interface appelle des contrôles DOM, clic et mobile ; un composant partagé peut exiger un parcours de bout en bout ; une règle d’accès doit être vérifiée pour les cas autorisés et refusés, dans l’UI comme dans l’API. Les labels Review AI et Review Human servent à orienter la relecture selon le risque, sans supprimer les contrôles obligatoires.
Les reviewers doivent examiner la même révision et la même base. Une preuve sur le commit A ne valide pas le commit B : il faut examiner le delta et rejouer les contrôles requis. Un statut skipped, cancelled ou pending n’est pas un succès. Un défaut récurrent devient ensuite un problème à traiter à la racine, avec comportement attendu, PR source, correction du test ou du contexte et nouvel essai sur d’autres cas.
Support officiel · Diapositives 10–12, 16–17.
Tugdual Grall et Xavier Noya : alléger le harness et accompagner l’adoption
Le passage de la complétion à la délégation oblige à réévaluer les outils et les habitudes.
- Réévaluer instructions et skills à mesure que les modèles évoluent, sur ses propres tâches.
- Comparer avec un agent peu configuré pour repérer les ajouts qui aident réellement.
- Éviter les procédures de spécification qui multiplient documents, validations mécaniques et grosses PR.
- Comparer le coût par résultat accepté, au-delà du seul nombre de tokens.
Lire le détail
Intitulé au programme : De la complétion au harness : 5 ans de Dev with AI, du code au métier. Programme officiel.
Intervenant : Tugdual Grall · Strategic AI GTM Lead @ GitHub. Fiche sur le site de la conférence.
Intervenant : Xavier Noya · Senior Software Engineer @ Betclic. Fiche sur le site de la conférence.
Tugdual retrace le passage de la complétion à la conversation, puis aux tâches déléguées depuis une CLI ou une application de gestion des agents. Xavier relie cette évolution à l’adoption chez Betclic : les habitudes d’IDE, la découverte de bases de code inconnues et la diffusion des nouvelles pratiques dans l’entreprise.
Ils invitent à réexaminer les instructions et les skills à mesure que les modèles et les environnements changent. Une pratique utile hier peut devenir redondante. Leur proposition consiste à tester un agent avec moins de couches, puis à reconstruire ce qui répond à des limites observées. Cette invitation ne permet pas de déduire que les contraintes métier ou les autorisations sont devenues inutiles.
Xavier raconte des essais intensifs de frameworks de développement guidé par les spécifications. Il rapporte une fatigue liée à la lecture de Markdown, aux demandes de validation et aux PR volumineuses, jusqu’à des acceptations mécaniques. Il conserve l’intérêt de la spécification, mais questionne le déroulé trop rigide et les questions qui n’aident pas à décider.
Tugdual décrit un benchmark récurrent sur une application pour comparer modèles, contextes et skills. Il privilégie le coût du résultat obtenu au seul volume de tokens. Xavier complète ce travail par des ateliers et une guilde interne permettant de partager les essais et de faire progresser l’adoption.
Compléments du support, 16 octobre 2026
Le support nomme Spec Kit, OpenSpec, BMAD et AI-DLC pour interroger leur valeur et leur surcharge face au besoin réel de planification et d’architecture. Il invite à adapter le niveau de méthode à la tâche. Cette comparaison n’est pas un classement chiffré et ne permet pas de conclure au rejet général de ces frameworks.
Les autres ajouts concernent l’apprentissage collectif, avec ateliers et partage de pratiques, les environnements permettant plusieurs agents en parallèle, et un flux qui part d’un échange Slack ou d’une réunion pour devenir une issue puis une PR à relire. Le contexte inclut mémoire, instructions et outils.
Support officiel · Diapositives 4, 6–9.
Philippe Prados : réduire les cycles et sélectionner le contexte
Réduire la facture d’un agent de code avec moins d’allers-retours, un contexte mieux sélectionné et des outils plus efficaces.
- Examiner les tours d’agent, le contexte réutilisé et les opérations d’outils pour agir sur les coûts.
- Sélectionner le contexte utile et regrouper les opérations ; le cache reste facturé.
- Comparer à qualité équivalente avant de conclure. Le facteur de réduction annoncé dans le titre n’est pas validé ici.
Lire le détail
Intitulé au programme : La guerre des tokens : Techniques avancées pour diviser par 3 votre facture LLM. Programme officiel.
Intervenant : Philippe Prados · IA Leader @ Carbon IT. Fiche sur le site de la conférence.
Le message de Philippe relie la facture d’un agent au nombre de tours, au contexte réutilisé et à la qualité des opérations disponibles. Sa fiche distingue le contexte fixe, la génération et les retours d’outils. Réduire une réponse finale ne traite donc qu’une partie du travail effectué par l’agent.
Sur le contexte, Philippe distingue le catalogue des outils de leurs descriptions et schémas effectivement récupérés : il décrit une étape de recherche différée des outils. Il recommande de choisir les MCP utiles avant la conversation et de conserver des descriptions de skills courtes. La fiche et le schéma sont donc à lire avec cette nuance, pas comme la preuve que tout outil installé est entièrement injecté à chaque tour.
Les préférences personnelles relèvent des instructions utilisateur ; les contraintes du projet, de ses instructions locales. Les règles spécialisées peuvent dépendre du type de fichier. Philippe propose aussi une mémoire partagée du projet pour éviter de reconstruire les mêmes recherches ou connaissances. Il reconnaît son coût et ne présente pas une stratégie de mémoire comme supérieure à toutes les autres.
Sur la génération, il recommande d’adapter séparément le modèle, l’effort de réflexion et le style de réponse. Une sortie concise vise les tokens visibles ; elle n’est pas un réglage direct du raisonnement interne. L’article propose de tester un modèle puissant à faible effort, sans fournir ici de benchmark permettant d’établir sa supériorité générale.
Sur les outils, l’objectif est d’accomplir une opération complète avec un résultat exploitable. Les exemples comprennent la recherche de symboles et le renommage par l’IDE ou le LSP, les modifications ciblées et groupées, le calcul confié à un programme et la compression des sorties par RTK ou des outils similaires, avec accès aux détails manquants.
Pour les boucles, il propose de regrouper les opérations, d’automatiser le formatage et d’intervenir lorsque l’agent dérive. Revenir au prompt initial avec les contraintes manquantes est une piste pour éviter l’accumulation de corrections. Ce conseil demande de préserver les résultats utiles et de vérifier le nouveau parcours sur la tâche concernée.
Philippe met en relation stabilité du préfixe et réutilisation du cache ; il donne l’exemple d’un horodatage changeant au début du prompt. Son simulateur examine l’amortissement de la compaction. Compacter après une pause est présenté comme une piste si le cache a réellement expiré et si la suite des échanges permet d’amortir l’opération. Chez Anthropic, les lectures et écritures de cache restent tarifées. Documentation Anthropic sur le prompt caching.
En fin de conférence, il décrit une configuration reconstructible : un projet dédié au paramétrage, des fragments d’instructions et des scripts d’installation pour plusieurs clients. Le but annoncé est de pouvoir retrouver un environnement propre après les essais et d’éviter les composants résiduels. Le compte rendu rapporte cette organisation ; il ne valide pas l’outil de compression cité.
Saif Jerbi : reconstruire la connaissance avant de réécrire
L’archéologie logicielle cherche les règles dans le code, les configurations et les données historiques.
- Reconstruire les règles dispersées dans le code, les configurations et l’historique avant de réécrire.
- Faire valider ces règles par les experts métier avant de produire le nouveau code.
- Comparer les sorties historiques sur les périmètres retenus et sur des périodes longues ; compiler ne suffit pas à valider le métier.
Lire le détail
Intitulé au programme : Archéologie logicielle à l’ère de l’IA. Programme officiel.
Intervenant : Saif Jerbi · Tech Lead @ TotalEnergies Digital Factory. Fiche sur le site de la conférence.
Saif décrit un système de raffinerie ancien dont la connaissance se disperse lorsque les experts partent ou changent d’équipe. Le code n’est qu’une partie du comportement : des traitements planifiés et des configurations contiennent aussi des règles. Une traduction automatique qui compile peut donc manquer ce que le système doit réellement faire.
Son parcours distingue l’analyse du legacy, la génération d’une documentation dans un format exploitable par les experts, puis la génération de code. La connaissance est partagée entre développeurs et sessions d’agents. Les experts valident et corrigent les documents avant le passage à l’implémentation, sur un périmètre que l’équipe peut absorber.
Il rapporte une limite de cette documentation : elle ne suffit pas toujours à faire émerger tous les cas. Le générateur peut revenir au code autorisé et aux configurations si une information manque. L’historique d’exécution et les sorties du legacy servent de matière aux tests de comparaison. Élargir les périodes examinées permet de découvrir des cas invisibles dans un premier échantillon.
Saif décrit aussi une séparation des accès entre le code de l’entreprise et celui d’un éditeur, après un examen interne des contrats. Les interfaces MCP encadrent l’accès aux API et aux données. C’est le récit du dispositif de son projet ; ce document ne tire aucune conclusion juridique sur d’autres logiciels ni sur la suffisance de ces contrôles.
Compléments du support, 16 octobre 2026
Le ZIP contient deux éditions, claire et sombre, du même support. Le cas décrit environ deux millions de lignes PL/SQL, plus de 200 packages et 200 jobs. L’outillage associe Claude Code, un accès MCP aux API et à la base du legacy, RTK et LikeC4.
Le workflow sépare trois responsabilités : reconstruire la documentation et les règles depuis les sources accessibles ; faire corriger et valider ce périmètre par les experts dans Confluence ; générer du Python puis comparer son comportement aux données historiques. Les exemples incluent heures creuses, changement d’heure et compteurs inactifs. Étendre l’historique de trois mois à six mois puis un an sert à découvrir les cas absents du premier échantillon. Les résultats et durées restent ceux du retour d’expérience, sans extrapolation à une migration complète.
Support officiel · HTML : architecture, workflow, amélioration continue.
Jean-Louis Rigau : mesurer les workflows et leurs évaluateurs
Intervention retrouvée dans la seconde moitié de l’enregistrement de Saif Jerbi.
- Fixer les critères de qualité, coût et répétabilité avant de comparer les workflows.
- Tester aussi l’évaluateur, avec des variantes correctes de référence et des défauts connus.
- Conserver les traces et la version de l’évaluateur pour comprendre les variations de score.
- Le support précise deux protocoles distincts : r07a (60 résultats) et r08 (90 essais). Les petits effectifs limitent la généralisation.
Lire le détail
Intitulé au programme : Nos workflows agentiques s’améliorent-ils vraiment ? Programme officiel.
Intervenant : Jean-Louis Rigau · Vibe coder & AI-native advisor @ Manufacture. Fiche sur le site de la conférence.
Jean-Louis part d’une question expérimentale : ajouter un skill, une review ou un nouveau modèle améliore-t-il le résultat sur une tâche donnée ? Il propose de définir la réussite avant les essais, d’enregistrer les exécutions et de comparer qualité, coût et répétabilité. La comparaison doit porter sur ses propres tâches, pas seulement sur des classements publics.
L’application d’exemple gère des contrats. Le cas étudié ajoute une bibliothèque de clauses, avec une exigence d’absence de doublon lors d’un retry. Le compte rendu rapporte 19 critères d’acceptation et 60 exécutions. Le support récupéré le 16 octobre confirme 3 modèles, 4 workflows et 5 répétitions pour le protocole r07a. Les configurations distinguent l’agent seul, l’ajout du skill, une review suivie d’une correction et leur combinaison.
Les résultats présentés montrent des apports limités ou dépendants de la configuration. Un skill peut inciter à tester le bon cas tout en produisant un mauvais résultat attendu. Une review peut manquer un défaut si elle ne sait pas où chercher. Dans une autre étude, le workflow installé n’est pas toujours exécuté, et forcer toute la chaîne peut augmenter le coût ou mener à un timeout. Jean-Louis souligne lui-même la petite taille de certaines séries.
Le second sujet est la qualité de l’évaluateur. Il peut refuser une solution correcte ou accepter un défaut. Jean-Louis décrit une implémentation de référence, des variantes correctes, des erreurs volontaires, du mutation testing et des critiques par d’autres modèles. Il conserve les traces et compare des versions de l’évaluateur sur les mêmes sorties, plutôt que de faire disparaître les anciens verdicts.
Il montre qu’un historique bloqué après une erreur de chargement, non détecté par une version, apparaît dans la suivante. Le classement apparent change alors sans nouvelle implémentation. Les incidents d’infrastructure doivent aussi être identifiés pour comprendre ce que mesure le score. Le message du talk est de réévaluer un workflow après un changement de modèle ou de tâche et de tester ses instruments de mesure.
Compléments du support, 16 octobre 2026
Le protocole r07a est maintenant explicite : 3 modèles × 4 workflows × 5 répétitions, soit 60 résultats, sur 19 critères. C0 désigne l’agent seul, CB l’ajout du skill, CR une review puis correction et CBR leur combinaison. L’évaluateur est déterministe, sans LLM. Avec sa version v5, la ligne Opus 5.5 passe de 4/5 pour C0 à 2/5 pour CB ; ces petits effectifs ne suffisent pas à établir une règle générale sur les skills.
Une deuxième étude, r08, compte séparément 90 essais : 3 modèles × 3 configurations × 10. Pour Opus 5.5, le tableau indique 7/10 et 2,9 $ en baseline, 8/10 et 5,5 $ avec Superpowers, puis 10/10 et 13,5 $ avec Superpowers strict. La réussite de la tâche et le respect de toute la séquence sont deux mesures distinctes : la dernière configuration suit entièrement le workflow dans 7 cas sur 10. Ces résultats ne doivent pas être mélangés avec r07a.
La comparaison v4/v5 réévalue les mêmes candidats, sans les régénérer. Elle ajoute la détection d’un historique bloqué après une erreur de chargement : les 5/5 apparents avec et sans skill deviennent respectivement 2/5 et 4/5. Le support documente aussi des faux rejets liés à un astérisque dans un libellé. Geler le protocole, conserver les empreintes et les versions de verdict, séparer les incidents d’infrastructure et éprouver l’évaluateur font donc partie de l’expérience.
Support officiel · Diapositives 7–14, 18–21.
Bathilde Rocchia : relier le développement à la découverte utilisateur
2 projets solo lui servent à comparer le travail avant et après l’implémentation.
- Recueillir des retours utilisateurs avant l’implémentation pour orienter les choix produit.
- Accélérer la production avec l’IA tout en conservant des ajustements manuels.
- Garder la maîtrise de l’expression personnelle : l’automatisation des publications a aussi suscité de l’inconfort dans son expérience.
Lire le détail
Intitulé au programme : Comment j’ai fait évoluer mon flow de création d’app en 18 mois. Programme officiel.
Intervenant : Bathilde Rocchia · iOS Developer @ Vivace App Studio. Fiche sur le site de la conférence.
Bathilde compare une première application de lutte contre la sédentarité à une seconde, Ventilate, qui aide à choisir quand ouvrir les fenêtres selon les conditions. Le changement décrit commence par davantage de témoignages et de retours utilisateur. Les informations accumulées deviennent un matériau de conception et de planification dans des fichiers Markdown.
L’IA intervient dans le développement mobile, mais aussi dans les visuels de publication et le site. Bathilde raconte une connexion entre Figma et son agent, et conserve la possibilité de retoucher manuellement ce qu’elle n’arrive pas à obtenir. Pour le site, elle préfère finalement Astro et des contenus pilotés depuis le dépôt à un CMS qu’elle n’utilisait pas pour publier.
Elle rapporte aussi une limite de l’automatisation des réseaux sociaux : des publications automatiques lui donnent le sentiment de perdre la maîtrise de son projet. La recherche de bêta-testeurs et les contacts directs restent une part de son travail. Le compte rendu conserve cette distinction entre accélérer une production et obtenir des retours qui orientent le produit.
Ses conclusions portent sur le périmètre qu’elle comprend et peut automatiser, les interviews utilisateurs et le dépôt Git qui rassemble les connaissances. Ce dernier contient les retours, les décisions et les recommandations de diffusion, au-delà du code.
Compléments du support, 16 octobre 2026
Le support précise les usages autour du produit : accès à l’API Apple Ads depuis Cursor puis Codex, variantes de captures pour les stores, retouches dans Figma et site Astro alimenté en Markdown. L’IA intervient aussi sur la distribution et la présentation, pas seulement sur le code de l’application.
Bathilde compare BreathInU et Ventilate : elle annonce pour Ventilate trois semaines de développement, deux stores et plus de mille téléchargements le mois du lancement, contre plus d’un mois, iOS seul et environ cent téléchargements pour BreathInU. Les produits, plateformes et conditions de lancement diffèrent : ces chiffres ne mesurent pas un effet causal de l’IA. Ses recommandations finales portent sur la recherche utilisateur, une base de connaissances dans Git et l’automatisation de ce que l’on comprend.
Support officiel · Diapositives 12–14, 17–22.
Rémi Lakmeche : construire HorseBrokers et chercher ses clients
Intervention retrouvée après Bathilde, dans le même enregistrement.
- Partir du problème métier pour cadrer HorseBrokers avec BMAD et Claude Code.
- Garder les arbitrages et ajouter ses contrôles de sécurité, d’environnements et de suivi.
- Traiter la prospection et les essais commerciaux comme un travail distinct du développement.
Lire le détail
Intitulé au programme : HorseBrokers - une app construite dans un langage que je n'ai jamais connu. Programme officiel.
Intervenant : Rémi Lakmeche · CTPO @ The One Studio. Fiche sur le site de la conférence.
Rémi présente HorseBrokers comme un produit pour les courtiers en chevaux de sport. L’application centralise les chevaux, leurs résultats et leurs documents, permet la recherche selon les besoins d’un acheteur et facilite le partage de fiches. Le problème métier vient de sa connaissance du terrain, puis sert de point de départ au projet.
Il décrit un développement solo avec BMAD et Claude Code, sur une stack mobile qu’il ne maîtrisait pas auparavant. Son expérience de projets l’aide à définir le brief, le design, l’architecture, les règles des flux de données et les stories avant l’implémentation. La délégation porte sur le code, tandis qu’il garde le cadrage et les arbitrages.
Son retour insiste sur ce qu’il a dû ajouter : tests et contrôle avant les commits, environnements de staging et de production, versionnement des API, audits de sécurité et de montée en charge, surveillance des erreurs et du trafic. Selon lui, ces pratiques n’étaient pas assurées nativement par la combinaison outil/méthode. Les sous-agents servent à paralléliser l’implémentation sous coordination.
Il indique que le MVP est en ligne sur iOS et Android, mais décrit la prospection comme une difficulté distincte. Montrer l’application aux personnes qu’il connaît ne suffit pas à atteindre des clients. Il raconte des échanges directs lors de concours et d’événements pour obtenir des essais et vendre le produit. Les comptes d’utilisateurs, revenus et volumes de tokens ne sont pas validés dans ce compte rendu.
Compléments du support, 16 octobre 2026
Le choix technique répond à une contrainte métier précise : les concours équestres ont parfois une mauvaise connexion, d’où un fonctionnement hors ligne avec SQLite dans l’application React Native/Expo. Le backend décrit utilise Fastify et PostgreSQL, avec Drizzle ; le support mentionne aussi Railway, R2 et Sentry.
Le workflow BMAD déroule brief, PRD, architecture, epics, stories, code et tests. Rémi décrit des hooks pre-commit et pre-push, des tests unitaires, d’intégration, API et mobile, un environnement de staging et des audits de sécurité à chaque évolution majeure. Les 1 700 tests et autres volumes affichés restent des déclarations du support : leur nombre ne démontre ni la couverture des risques ni la qualité de chaque assertion. Le dossier ne vérifie pas le coût total ni l’adoption commerciale.
Support officiel · HTML : stack, workflow, qualité, chiffres.
Patrick Szymkowiak : de RTK open source aux besoins des équipes
Genèse de RTK, adoption open source et passage aux besoins des équipes avec RTK Pro.
- Relier la compression des sorties CLI de RTK aux usages et aux besoins des équipes.
- Travailler l’attribution des coûts, les règles d’équipe et le partage des pratiques.
- Les filtres personnalisés viennent aussi des utilisateurs ; réduire les tokens de sortie ne mesure pas le coût total.
Lire le détail
Intitulé au programme : rtk : d'un CLI Rust à 80k stars à une startup qui facture. Programme officiel.
Intervenant : Patrick Szymkowiak · CEO @ rtk-ai labs. Fiche sur le site de la conférence.
Découvrir les outils : RTK · RTK Pro.
Les thèmes de l’intervention relient un outil de compression des sorties de commandes pour les agents de code, son adoption open source et le développement de RTK Pro.
Rendre la valeur visible. La visibilité des gains et les contributions de la communauté soutiennent la diffusion d’un outil. À retenir : permettre aux utilisateurs de voir son bénéfice et de partager leurs usages. Réduire le volume de sorties transmis au modèle ne démontre toutefois pas, à lui seul, une baisse équivalente de la facture totale.
Passer de l’usage individuel aux besoins d’équipe. L’attribution des coûts par projet et développeur, les politiques de sécurité et la distribution des pratiques et des skills figurent parmi les besoins évoqués pour RTK Pro. L’objectif est de faciliter l’arrivée des développeurs avec un cadre commun. Ce sont des axes de positionnement, pas un bilan d’efficacité du produit.
Laisser les utilisateurs adapter l’outil. Une piste pour le projet est de permettre aux utilisateurs de personnaliser leurs filtres et de partager leurs usages, au lieu de chercher à anticiper tous leurs besoins. Elle complète la discussion sur les harness et la sélection du contexte.
Compléments du support, 16 octobre 2026
Le gain de 60 à 90 % annoncé concerne la réduction des sorties de commandes. Il ne représente pas directement une économie identique sur tout le contexte ou sur la facture. Les téléchargements de binaires et les étoiles GitHub ne comptent pas des utilisateurs actifs uniques ; les logos issus des organisations de stargazers ne prouvent pas une relation commerciale.
Le support distingue le CLI disponible, rtk-engine présenté comme bêta non encore publiée, et des fonctions de RTK Pro à différents stades. La chaîne envisagée couvre hooks, filtrage, routage et politiques. La portée annoncée de certains contrôles varie aussi selon l’intégration, notamment entre Claude Code et les seuls résultats MCP dans Cursor. Les fonctions à venir et la mémoire partagée en cours de revue restent des annonces du support, pas des capacités testées ici.
Support officiel · Diapositives 6–13, 17, 20–21.
Katia Gil Guzman : créer des applications pour les humains et les agents
Developer Experience chez OpenAI. Concevoir des applications où humains et agents collaborent.
- Extensions, WebMCP et annotations permettent de partager l’état utile de l’application entre humains et agents.
- Aisle, ArchMorph et JupyterLite illustrent des actions exposées à l’agent et des interfaces conservées pour l’humain.
- Le support complète le programme ; la disponibilité actuelle des API et leur comportement ne sont pas vérifiés ici.
Lire le détail
Intitulé au programme : Créer des applications pour les humains et les agents. Programme officiel.
Intervenant : Katia Gil Guzman · Developer Experience @ OpenAI. Fiche sur le site de la conférence.
Thème annoncé : considérer les agents IA comme un nouveau type d’utilisateur. Le descriptif invite à repenser la conception des logiciels et les interactions avec eux pour permettre aux humains et aux agents de collaborer au sein des applications.
Compléments du support, 16 octobre 2026
Le support complète désormais le thème annoncé avec trois mécanismes concrets. Les extensions ajoutent des points d’entrée, panneaux interactifs et visualiseurs de fichiers. WebMCP expose des actions de l’application à l’agent depuis la page ouverte, en réutilisant sa logique et les permissions de la session connectée. Les annotations relient une sélection dans l’interface à l’intention de l’utilisateur et au contexte envoyé à l’agent.
Les exemples couvrent Aisle pour un plan de salle et des places épinglées, ArchMorph pour une représentation partagée de l’habitat en 2D/3D, et JupyterLite pour des cellules non enregistrées et un noyau partagé. L’enjeu est de donner accès à l’état utile de l’application et aux actions pertinentes, tout en conservant une interface pour l’humain.
Les dernières slides rapprochent Sites, WebMCP, annotations, serveurs MCP et interfaces MCP Apps. Ce compte rendu décrit les mécanismes et démonstrations du support ; il ne certifie ni la disponibilité actuelle de chaque API ni leur comportement dans une application déployée.
Support officiel · Diapositives 8, 10–13, 15–16.
Annonces et suites
📚 Greg Lhotellier : annonce des formations Dev With AI
Les formations annoncées par Greg pour apprendre à développer avec Claude Code et industrialiser son workflow.
Greg annonce des formations sur les fondations de Claude Code et l’organisation des workflows d’équipe. Le détail reprend le catalogue consulté pour ce compte rendu ; les dates sont à vérifier auprès de Dev With AI.
Lire le détail
Greg a annoncé les formations Dev With AI. Le catalogue officiel présente deux formations d’une journée :
Développer avec Claude Code, les fondations, avec Aurélien Binder-Meunier : configurer son agent, documenter son projet, déléguer du code et vérifier le résultat. Prochaine session en ligne : 23 novembre 2026.
Industrialiser son workflow avec Claude Code, avec Florian Bruniaux : organiser la review et la correction, automatiser les contrôles et suivre le coût du résultat accepté. Prochaine session en ligne : 24 novembre 2026.
Deux formats sont proposés : sessions interentreprises en ligne à dates fixes, ou formations pour une équipe, sur place ou à distance, adaptées à son contexte.
5 essais pour vérifier ce qui convient à son équipe
Pistes de suivi proposées par l’auteur du compte rendu. Aucun engagement n’a été convenu pendant la conférence.
Ces pistes de suivi sont proposées par l’auteur : choisir un cas, comparer les workflows et tester les contrôles. Conserver les résultats, les échecs et les interventions humaines permet d’examiner ce qui aide sur le périmètre choisi.
Lire le détail
- Choisir un changement et définir sa réussite
Fixer les comportements attendus, les cas limites et les vérifications avant d’ajuster le workflow. Conserver ces critères pendant la comparaison. Inclure les effets métier, pas seulement la compilation.
- Comparer un harness minimal à la configuration actuelle
Rejouer une tâche comparable avec et sans une couche précise, par exemple un skill ou une review supplémentaire. Enregistrer ce qui a réellement été exécuté, les sorties, les échecs, les coûts et les interventions humaines. Répéter pour observer la variabilité.
- Relire une conversation et les retours de review
Retrouver l’intention initiale, les moments de dérive, les recherches évitables et les décisions. Vérifier les findings contre le code et les règles métier avant d’accepter un correctif. Choisir une cause répétée à corriger dans le système.
- Tester les instruments de contrôle
Introduire un défaut connu et une variante correcte. Vérifier que les tests ou l’évaluateur distinguent les 2. Conserver séparément les verdicts des versions de l’évaluateur et identifier les incidents d’infrastructure.
- Vérifier l’usage et la livraison
Pour un legacy, comparer aux sorties historiques sur des périodes couvrant les cas retenus et faire valider les règles par un expert. Pour un produit, obtenir des retours de ses utilisateurs. Suivre l’attente de review, les reprises et les résultats après livraison avant d’attribuer un gain à la génération.
Ces essais demandent un périmètre choisi et des preuves conservées. Leurs résultats dépendent de la tâche et du contexte de l’équipe.
📸 La journée en photos
30 photos de la conférence du 12 octobre 2026 au Forum des Images. Cliquez sur une photo pour l’agrandir.
Les photos permettent de retrouver les moments de la conférence. Ouvrez la galerie puis cliquez sur une image pour l’agrandir.
Lire le détail
Les 16 intervenants et leurs profils LinkedIn
Liens récupérés dans les cartes « Celles et ceux qui prennent la parole » du site officiel, consulté le 13 octobre 2026.
Les profils et rôles proviennent du site officiel de la conférence. Ils décrivent les personnes et fonctions présentées pour cette édition, avec leurs liens LinkedIn.
Lire le détail
Les fonctions ci-dessous sont celles affichées pour la conférence. Les liens LinkedIn proviennent du site officiel, sans recherche par homonymie. Les profils LinkedIn eux-mêmes n’ont pas été ouverts.
Le comité de contenu : choisir les intervenants et les sujets
Marek Kalnik, Laetitia Lanfranchi et Arthur Magne composent le comité chargé de la sélection des speakers et des sujets.
Marek Kalnik, Laetitia Lanfranchi et Arthur Magne composent le comité chargé de sélectionner les intervenants et les sujets. Le détail reprend leurs présentations sur le site officiel.
Lire le détail
Le comité de contenu prépare le programme en sélectionnant les intervenants et les sujets. Le site officiel présente 3 profils qui croisent les perspectives de startups, d’ESN et de grands groupes de la tech.
Marek Kalnik, Group Partner chez Theodo et ancien CTO, accompagne les équipes techniques et leur organisation. Ses sujets incluent le software craftsmanship, le leadership tech et les effets de l’IA sur le travail des développeurs.
Laetitia Lanfranchi, ingénieure entrepreneure, accompagne via BotBloom l’adoption de workflows agentiques, la modernisation de systèmes legacy et le développement de produits augmentés par l’IA.
Arthur Magne, cofondateur et CTPO de Packmind, travaille sur le partage de connaissances entre développeurs et agents IA, avec un intérêt particulier pour le Context Engineering.
Présentation synthétisée depuis la rubrique officielle du comité, consultée le 13 octobre 2026.
Remerciements
Merci Greg !
À Greg Lhotellier, fondateur de Dev With AI et organisateur de cette première conférence.
Remerciements à Greg Lhotellier pour l’organisation de cette première édition. Retrouvez aussi les liens vers la communauté et les formations annoncées.
Lire le détail
Merci Greg pour l’organisation de cette première édition de Dev With AI et pour avoir réuni la communauté autour de retours d’expérience concrets !
Apprendre et rencontrer : les 2 objectifs que tu donnes à la conférence donnent aussi le ton de ce récap. Merci pour le travail consacré à faire vivre Dev With AI et les rencontres entre développeuses et développeurs.
Pour continuer les échanges : la communauté Dev With AI, le Slack et les formations annoncées.
Pour aller plus loin
Programme, ressources des intervenants et liens vers les outils permettent de retrouver les sources du dossier.
Lire le détail
Conclusion
Les interventions décrivent des pratiques de génération, de collaboration, de contrôle et de création de produits. Pour les mettre à l’épreuve dans son équipe, choisir un cas mesurable, éprouver les contrôles et conserver les retours métier.
Liens utiles
- Programme officiel Dev With AI · 13 octobre 2026 · Observation vérifiée
- Article CARBON : La guerre des tokens · 12 octobre 2026 · Source documentaire
- Philippe Prados : Optimiser les tokens, vidéo de la conférence · 13 octobre 2026 · Source documentaire
- Documentation Anthropic : prompt caching · 13 octobre 2026 · Observation vérifiée
- Formations Dev With AI · 13 octobre 2026 · Observation vérifiée
- Les intervenants et leurs profils LinkedIn · 13 octobre 2026 · Observation vérifiée
- RTK : site officiel · 13 octobre 2026 · Source documentaire
- RTK Pro : site officiel · 13 octobre 2026 · Source documentaire
Supports récupérés le 16 octobre 2026
- Guillaume Laforge · PDF
- Dorra Bartaguiz · PDF
- Marek Kalnik · PDF
- Alexandre Jeambrun · KEY
- Florian Bruniaux · HTML
- Tugdual Grall et Xavier Noya · KEY
- Saif Jerbi · ZIP
- Jean-Louis Rigau · PDF
- Bathilde Rocchia · KEY
- Rémi Lakmeche · HTML
- Patrick Szymkowiak · PDF
- Katia Gil Guzman · PDF
Mise à jour du 16 octobre 2026 : les 12 supports disponibles dans le programme ont été examinés, avec des compléments datés dans chaque intervention. Les slides de Brevo et de Philippe Prados restent absentes de la page consultée. Les chiffres sont attribués aux intervenants, sans réplication indépendante.