Croissants, reviews et coupure de courant: Marmelab à la Dev With AI

Nous avons assisté à la première édition de la conférence Dev With AI à Paris. Organisé par Greg Lhotellier et sa communauté, ce sont 14 talks qui se sont enchainés à propos du développement avec l’intelligence artificielle.

Première question de la journée: “Qui peut encore coder sans Claude Code ?”. Personne n’a levé la main, nous non plus.

Que pouvons-nous dire de cette édition ? Nous sommes globalement mitigés. D’un côté nous avons assisté à des talks qui servaient simplement de publicités pour des sponsors de l’événement. D’un autre, nous avons eu le sentiment que beaucoup de talks se ressemblaient, sans apporter de plus-value entre eux. Il y avait un petit côté Slop IA, mis à l’échelle d’une conférence.

(La matinée a été marquée par une coupure de courant, ce qui a décalé le programme d’une heure, nous avons donc raté les deux derniers talks: Les Indie et celui d’OpenAI.)

Pour nuancer, deux talks nous ont particulièrement marqués.

La Conversation Review par Marek Kalnik

Marek est CTO à Theodo. Et il part d’un constat que nous vivons tous les jours en tant que développeurs. Depuis 2008 et l’introduction des pull requests par GitHub, ce sont les PR qui permettent principalement à une équipe de discuter du code. Par ce biais, elles permettent également de faire progresser un développeur individuellement via les commentaires et les retours reçus sur son code.

Sauf qu’aujourd’hui, un agent IA va ouvrir des PR de 500 fichiers, rendant ces PR de moins en moins lisibles pour un humain. Que fait-on ? On demande à un autre agent d’effectuer une review, et pendant que Claude réfléchit, nous scrollons (sur le blog de Marmelab, évidemment) ou travaillons sur autre chose. “Est-ce que c’est ça notre Job maintenant?”, interroge Marek.

Un agent IA réalise du code de plus en plus propre et cohérent, rendant l’intervention humaine de moins en moins nécessaire. Son idée est que “peut-être” la review de code devient inutile, et que la véritable valeur du développeur se situe ailleurs.

Marek suggère de déplacer la revue sur la conversation entre un développeur et son agent IA. C’est directement pendant cette conversation que les décisions se prennent, là que les erreurs se glissent, et c’est là que la valeur du développeur se trouve.

Ce qu’on cherche à valider sur une conversation :

• Réalise la tâche la plus grosse possible.
• Fait la tâche correctement.
• Minimise le coût.
• Dépendance humaine minimale.
• Le moins possible d’étapes, pour éviter les cycles inutiles.
• Un haut taux de réussite.
• Reste en contrôle sur le scope. Pas de dérapage.

Pour illustrer son propos, Marek nous dévoile une session où il demandait une stratégie pour intégrer un modèle style Jev pour trier ses emails. Seulement une stratégie. L’agent IA a fait plus que ça sans aucun consentement. Il a rédigé 1867 lignes de code, et il est aussi allé fouiller dans les node_modules de son dossier. Au total sa session a coûté 17$ pour 248K tokens. Dans le diff final, rien n’indiquait qu’il avait fait tout cela sans consentement.

Marek propose de formaliser cette approche en 3 piliers de revue:

• Intention : le dev a-t-il bien posé le problème ?
• Preuves : sur quoi s’est-il appuyé pour accepter le résultat ?
• Contrôle : a-t-il gardé la main sur le scope, le contexte, les outils et les permissions ?

Pour en faire une habitude, il propose un rituel : 10 minutes par jour pour analyser une vraie session, repérer l’étape qui a tout fait basculer, et tester une amélioration. Il y a tout à apprendre dans ce domaine, chaque session est une opportunité de s’améliorer.

C’est notre coup de cœur de la journée. Le cadre tient en 3 questions, il s’applique à notre quotidien, et nous pouvons l’adopter dès le lendemain de cette conférence.

La guerre des tokens par Philippe Prados

Philippe Prados (Carbon IT) va vite. Mais il a énormément de conseils à nous partager sur la manière de réduire notre consommation de tokens et donc notre facture.

Le constat est simple, dans un harnais, chaque résultat d’outil relance un cycle agentique. Il faut donc optimiser chaque étape pour réduire la consommation de tokens et éviter les cycles inutiles.

Voici quelques conseils que nous retenons:

• Passer /doctor régulièrement sur son Agents.md et skills. L’évolution des modèles fait que de plus en plus de skills se retrouvent dans les modèles suivants et deviennent redondants.
• Faire le ménage dans les MCP. Il ne garde que ceux qui font le travail en un appel, avec une réponse courte. Un wrapper d’API n’a rien à faire là, trop coûteux, comme le suggérait Guillaume dans son article sur les MCP.
• Garder le contexte sous 50 %, à coups de /clear et /compact. Philippe conseille de le faire en revenant de la pause déjeuner. En effet le cache a expiré pendant la pause, et va donc consommer des tokens pour relire le contexte, quitte à consommer ces tokens, autant les utiliser pour faire un /compact. Ces commandes étaient d’ailleurs suggérées dans l’article de Guillaume sur les commandes Claude à connaître.
• Choisir le modèle selon la tâche : un gros pour planifier, un moyen pour coder, un petit pour le répétitif.
• Ne pas laisser le LLM faire des calculs. Un calcul sur des nombres à 10 chiffres lui coûte 510 tokens. Utiliser des MCP spécialisés à la place (mcp-server-calculator par exemple).
• Revenir en arrière plutôt que de corriger : le cache repart du dernier point commun, et la suite coûte moins cher.
• Utiliser un mcp d’indexation pour la recherche dans le code. Ça évite de faire des greps fastidieux et améliore la rapidité et la précision des recherches.

Il nous a aussi parlé du fait d’utiliser “caveman” ou de compresser l’agents.md via des outils. Si le sujet vous parle, Erwan et Jérôme ont testé cinq plugins de ce genre cet été.

En tout cas, le fait que ça soit des conseils concrets et applicables en fait un talk très utile pour tous les développeurs utilisant des agents IA.

Cerise sur le gâteau, Philippe a condensé tous ses conseils dans un cheat sheet, disponible sur leur site.

Et le reste de la journée ?

Nous allons passer le premier talk de la journée sur Antigravity. Même si le speaker était sympathique, il ne s’agissait que d’une publicité pour le produit, et la landing page est aussi pertinente. Heureusement les croissants étaient bons.

Beaucoup de talks partageaient le même message : le goulot passe de l’écriture du code à sa vérification, le harness compte plus que le modèle, et l’humain reste indispensable. C’est juste, mais à force de l’entendre sans voir comment le mettre en pratique, la journée a parfois tourné en rond. On vous liste plutôt les points clés que nous avons retenus.

Software Factory : l’IA collaborative chez Brevo (Mickaël Arias et Maxence Bourquin, Brevo).

Ils expliquent que tous les développeurs peuvent travailler sur n’importe quelle partie de la codebase. Pour ce faire, chaque “garant” d’une section doit documenter soigneusement cette section, afin que les autres puissent comprendre rapidement le contexte et les règles spécifiques. Un garant reste responsable de sa section et doit valider les modifications apportées par les autres. Mais un développeur peut donc contribuer à n’importe quelle section tant qu’il respecte les règles et le contexte documentés.

Les revues sont préparées par une première boucle d’IA et une classification est mise en place : TOFIX pour les éléments à corriger, NOTE pour les remarques informatives, et WONTFIX pour les points qui ne seront pas traités. Un humain tranche ensuite pour dire si cette classification est correcte. La revue humaine n’est pas supprimée, mais préparée par un agent IA au préalable.

Quand la vélocité explose : place au Harness Engineering (Dorra Bartaguiz, Arolla).

Un constat simple: sur un de ses projets, les tests générés par l’IA annoncent 100 % de couverture, pour 33 % en réalité. Pour améliorer cela elle applique les pratiques du software craftsmanship ou dans les principes du shift-left à son harness. En définissant le besoin qu’elle découpe en règles, et illustre par des cas concrets, elle permet de cadrer l’agent. Dorra nous parle aussi de TDD comme outil de contrôle de l’agent et de mutation testing comme outil de détecteur de mensonge. Si notre couverture de test est bonne mais que le mutation testing échoue, cela indique que notre harness n’est pas fiable. Cette conférence a mis en avant le fait que nous avons déjà les outils pour améliorer nos harness. En bref, appliquons les bonnes pratiques et les concepts de conception logicielle, que nous connaissons en tant que dev, à nos agents. Cela peut sembler tomber sous le sens, mais ça ne fait pas de mal de se le rappeler de temps en temps.

Photo : FBI, domaine public, via Wikimedia Commons.

De la complétion au harness : 5 ans de Dev with AI (Tugdual Grall, GitHub, et Xavier Noya, Betclic).

Cette conférence retrace l’évolution fulgurante du développement, passant de la “timide” complétion de Copilot dans VS Code, jusqu’aux ADE (Agent Development Environment). Tugdual nous parle de la migration d’un projet de TypeScript vers Rust faite par un seul dev en 3 semaines, là où l’équipe estimait 2 ans à 3 devs. Et un bon conseil : tester ce que l’agent sait faire seul avant d’écrire un skill et de tester nos skills. Nous avons une petite frustration sur le fait qu’ils ne nous aient pas montré comment tester la pertinence de nos skills, mais cela est un sujet à part entière. Ils mettent également l’accent sur le fait d’accepter le changement et de se remettre en question en permanence pour se donner une chance de suivre les évolutions rapides du développement avec l’IA.

Nos workflows agentiques s’améliorent-ils vraiment ? (Jean-Louis Rigau, Manufacture).

Jean-Louis nous explique que les modèles possèdent des benchmarks nous expliquant comment les performances évoluent avec les différentes versions. Mais que se passe-t-il sur les performances couplées à nos workflows agentiques, à nos harness ? Est-ce que j’ai un meilleur résultat avec un agent seul, avec un agent + des skills, ou avec un agent + des skills + une review ? Pour vérifier ça, il a mesuré 60 runs de son workflow avec 4 modèles différents. Sur son cas, ses skills et sa review n’apportent presque rien et coûtent jusqu’à 3,70 $ de plus par essai, alors qu’un modèle plus récent fait mieux, seul et pour moins cher. Le résultat nous intéresse, mais la présentation nous a semblé un peu fouillis. Ce que nous retenons c’est qu’il est très difficile de mesurer les performances d’un workflow agentique, et que ces mesures sont, de toute façon, très liées au projet. Mais l’exercice peut faire remonter des conclusions surprenantes et nous permettre d’améliorer nos pratiques.

Moderniser un SI de 30 ans grâce à une Usine Agentique (Alexandre Jeambrun, Octo) et Archéologie logicielle à l’ère de l’IA (Saif Jerbi, TotalEnergies).

Photo : Erik Pitti, CC BY 2.0, via Wikimedia Commons.

Deux retours d’expérience sur du legacy massif : 33 millions de lignes pour l’un, 2 millions de lignes de PL/SQL sans documentation pour l’autre. Le constat pour les deux est le même, il faut comprendre le code, et surtout le métier, avant d’en générer. Donc on va extraire les connaissances implicites du code, les formaliser et les faire valider par des experts métier avant de générer du nouveau code. Un point qui a attiré notre attention est le fait que l’agent s’en sort mieux s’il a à la fois la connaissance du code et la connaissance métier.

Conclusion

Dans l’ensemble, nous ressortons un peu mitigés. Les talks nous ont surtout confirmé des retours d’expérience que nous connaissions déjà : l’importance de comprendre le code avant de générer du nouveau, la nécessité de formaliser les connaissances implicites et de les faire valider par des experts métier, et les limites actuelles des workflows agentiques.

Malgré tout, cette journée nous a apporté quelques idées concrètes que l’on compte appliquer. Que cela soit le Conversation Review pour mieux comprendre et améliorer notre utilisation de l’IA, ou des pistes pour améliorer notre gestion du contexte et de notre consommation de tokens, dont les implications vont bien au-delà de la facture salée. De manière plus large, nous retenons que les modèles changent vite et que c’est le harness et la base de connaissance métier qui feront la différence. Bref, quelques portes enfoncées, mais aussi quelques nouvelles ouvertes.

Nous serons curieux de voir la prochaine édition, avec, nous l’espérons, plus de démos, plus de diversité dans le choix des sujets et peut-être un retour de diapo plus vivante avec moins d’IA ?