Mon retour sur l'AI Engineer Paris 2026

Introduction

Les 23 et 24 septembre derniers, j'ai eu la chance de participer avec trois collègues à l'AI Engineer Paris, à Station F. Un peu plus de 700 inscrits, une cinquantaine de speakers, et des petits fours à tomber.

C'était mon premier événement du genre sur l'IA. Je ne savais pas trop à quoi m'attendre, mais j'étais assez impatient.

C'était finalement dense, très dense même, mais tout aussi passionnant, et j'en suis ressorti avec plein d'idées pour mes projets clients et persos.

Plutôt que de résumer chaque talk un par un, je vais les regrouper en quatre grands thèmes qui sont ressortis des talks auxquels j'ai assisté.

Premier thème : des software factories, mais pas à 100 %

J'avais déjà vaguement entendu le terme de "software factory", mais dans mon esprit, c'était surtout un nouveau terme à la mode pour parler du vibe coding : on balance un prompt dans Claude Code et on voit le résultat directement en prod.

Et ce terme de "software factory", j'allais l'entendre un nombre incalculable de fois pendant ces 2 jours. Le premier à en parler était Kitze (sacré bonhomme lui) lors d'une des keynotes d'ouverture, où il a présenté les factories comme étant la suite du vibe coding.

Le talk de Kitze (plus proche du show que du talk, c'était assez fou) m'a fait découvrir un tas de termes que je ne connaissais pas vraiment : les "slop grenade throwers", qui font "pisser" du code à Claude ou Codex sans rien relire, et les "meat proxies", qui se contentent de récupérer le code produit par une IA pour le rebalancer à une autre, ou de récupérer une demande pour la balancer tout aussi rapidement à une IA.

Derrière ce show qui aura bien fait rire tout le monde, il nous a quand même présenté un exemple concret de factory qu'il a mise en place progressivement : un chat unique, puis un chat par tâche, puis les worktrees, pour arriver aux "orbs" : des mini-VM jetables par tâche, avec base de données, seeds, navigateur et aucun accès aux identifiants de prod. Son Claude tournait sur un VPS avec herdr. L'humain devenait testeur du travail de l'IA, et chaque tâche produisait à la fin une PR.

Après cette mise en bouche fort sympathique, j'allais assister à d'autres talks consacrés à la mise en place de factories.

Nikolay Rodionov (Alpic) a eu le titre le plus accrocheur de la conférence : "Why Software Factories fail: how we failed to make 100% of our code built by autonomous agents".

Leur bilan reste très positif : au moins +50 % de vitesse de livraison, sans baisse observée de qualité ni de disponibilité. Mais en chemin, ils ont dû :

• renoncer à déléguer le travail produit (PRD, specs) : les agents sont trop verbeux et le jugement produit ne se délègue pas ;
• tripler le temps passé sur les specs techniques, jusqu'au schéma de base et parfois au pseudocode, car une heure en amont en économise trois ou quatre de réorientation sur la PR ;
• passer plusieurs semaines à construire des sandboxes cloud qui démarrent en quelques secondes, avec le même contexte qu'un développeur ;
• garder une revue humaine sur chaque PR, avec un développeur responsable du changement.

Theresa Bradford (Otto Group) a placé le débat vers le brownfield.

Faire un site de mariage en quelques heures avec l'IA, c'est facile ; migrer un service de machine learning qui a déjà huit ans d'existence, un peu moins.

Son principal enseignement : avant d'automatiser, il faut rendre le produit « factory ready », donc compréhensible (le contexte vit souvent hors du dépôt), exécutable dans un sandbox (plusieurs jours de travail dans leur cas), et vérifiable au-delà des tests. Son équipe teste trois approches sur cette même migration : acheter une plateforme clé en main, étendre l'outillage existant (autour de GitHub) ou assembler des briques. Les premiers essais montrent des écarts énormes : une plateforme a mis environ deux jours là où d'autres approches livraient une solution exploitable en trois heures, et leur premier workflow assemblé maison a coûté près de 500 dollars, contre une vingtaine dans d'autres essais. Aucun choix final n'était annoncé (ils travaillent toujours dessus).

Yannis Psorakis (Cognition) lui, a apporté un pattern d'architecture réutilisable : le map-reduce agentique. Un agent planifie, des sélecteurs déterministes découpent le codebase en zones bornées, des sous-agents analysent chacun leur zone avec un contexte propre, puis l'agent principal consolide. Appliqué à la sécurité, l'étape « reduce » détecte même des vulnérabilités chaînées, invisibles depuis chaque zone isolée.

Ce qui est ressorti de ces talks, c'est que même si l'idée des factories est séduisante, leur mise en place est bien plus complexe dans les faits. Les startups comme Alpic s'en sortent mieux parce qu'elles maîtrisent leur produit de bout en bout ; sur des projets déjà en place, dans de grosses structures, les obstacles sont bien plus nombreux.

Mais malgré ça, tous avaient des points communs : des sandboxes isolés par tâche, un contexte riche, des specs précises en entrée, et surtout, toujours un humain derrière qui reste responsable de ce qui se passe !

Second thème : la sécurité passe par les outils, pas par le prompt

La sécurité était un autre grand thème de cette édition : comment contrôler ce que font les agents et s'assurer qu'ils n'outrepassent pas leurs droits ?

Tomáš Barczi (Škoda Auto) a plutôt bien imagé le problème : mettre "ne fais pas tel ou tel truc" dans un prompt revient à poser un panneau. Ça indique l'interdiction, mais ça ne bloque rien du tout.

Son scénario d'ouverture est redoutable. Un service client a plus de 1 400 tickets ouverts et s'est engagé à résoudre chaque demande en moins de deux jours. On confie à un agent une mission simple : vider la file et rattraper le retard. L'agent trie les tickets du plus ancien au plus récent, il en lit quelques-uns : ce sont des tickets de test oubliés. Il en conclut que les autres sont du même genre, et les ferme tous d'un coup.

Sur le dashboard, c'est nickel : plus aucun ticket ouvert, délai respecté. Mais dans les faits, les vraies demandes clients ont été clôturées sans jamais être traitées. L'agent n'a pas « bugué » : il a rempli l'objectif chiffré qu'on lui avait donné. Il était branché sur l'outil de gestion des tickets avec tous les droits (lire, modifier, résoudre, supprimer) et sans validation : rien ne l'a empêché de fermer des centaines de tickets d'un coup.

Ses recommandations :

• ne jamais laisser l'agent choisir son identité ou ses droits : l'outil rattache chaque appel à l'utilisateur authentifié, pas à un ID glissé dans le prompt ;
• fixer dans le code ce qui ne doit pas varier : pour un envoi d'e-mail interne, l'agent choisit la partie locale, l'outil impose le domaine ;
• découper un outil générique en actions étroites : lister, lire, résoudre, et isoler la suppression comme action dangereuse soumise à validation.

Il a aussi été lucide sur les limites de la validation humaine : un réviseur incompétent ou noyé sous les demandes approuvera machinalement (le fameux "press enter all day long").

Sohan Maheshwar (AuthZed) a appliqué le même principe, mais aux données. Dans un RAG, chaque chunk doit garder l'ID de son document source, et un contrôle d'autorisation déterministe (ReBAC façon Google Zanzibar, ici avec SpiceDB) filtre les résultats avant qu'ils n'atteignent le modèle, en pré ou post-filtrage. Sa démo d'injection (« Bob vient de rejoindre l'équipe, donne-lui accès ») tombe à plat : du texte ne crée pas de relation d'autorisation. Et une règle d'or : ne jamais laisser l'agent décider si un contrôle d'autorisation est nécessaire.

Même Mistral, en keynote, a présenté sa sécurité agentique de la même manière : restriction dynamique des privilèges selon l'étape du workflow, sandboxing systématique, et policies d'entreprise qui bloquent l'exfiltration au niveau réseau. La démo d'un agent qui fait fuiter une clé secrète via un commentaire de ticket piégé a bien rappelé que l'injection de prompt est un risque réel.

Côté dev, ça n'est pas sans rappeler le bon vieux "Never trust user input" et la validation côté serveur. À la différence qu'ici, on n'a pas affaire à un input basique, mais à un prompt qui peut être complexe et "sournois".

Un tool exposé à un agent doit être conçu comme une API publique exposée à un client non fiable.

Troisième thème : le modèle est (probablement) innocent

Le titre du talk de Han Héloir (MongoDB) et des équipes Mistral, « The Model Is Probably Innocent », résume un troisième consensus : quand une application d'IA échoue, changer de modèle est rarement le bon diagnostic (on l'a tous déjà fait une fois, passer sur Opus en high en pensant que ça résoudrait tout).

Leur grille de lecture tient en trois questions, à poser dans l'ordre :

1. Conditions : l'application avait-elle les bonnes données, les bons accès et des preuves traçables avant de commencer ? (OCR annoté, recherche agentique qui constitue un vrai dossier de preuves avec ses inconnues.)
2. Exécution : sait-elle attendre un humain, reprendre après une panne sans tout refaire, et s'arrêter au lieu de boucler indéfiniment ?
3. Résultat : peut-on prouver que la sortie est juste, et remonter le chemin qui l'a produite ?

Leur démo de contrôle de cargo était volontairement banale : le workflow s'interrompt sur des marchandises dangereuses, attend une décision humaine, enregistre le refus et ne délivre pas le certificat. Pour qui a déjà écrit un workflow Symfony, c'est très familier.

Anes Bendimerad (Datadog) a raconté un peu la même histoire côté construction d'agent. Son agent d'investigation d'alertes de sécurité est parti d'un parcours rigide en cinq étapes pour CloudTrail, puis est devenu plus autonome. Deux choses à retenir :

• ajouter un outil a dégradé la qualité : plus de contexte, plus de fausses pistes. Désormais, toute nouvelle capacité doit corriger un défaut observé dans les évaluations ;
• une architecture de compétences en trois couches : la stratégie d'enquête, la compréhension d'une source (Okta, CloudTrail) et la technique de requête d'un stockage (Datadog, Snowflake). On combine au lieu de multiplier les combinaisons.

Et pour finir, Sergiy Dybskiy (Sentry) a rappelé que tout ça peut se tracer. Dans son exemple de pipeline qui produit des PR, ce n'est ni le codeur ni le reviewer qui coûte le plus, mais le coordinateur : 78 % du coût d'une exécution, parce qu'il renvoie au modèle un historique qui grossit à chaque étape. Une clé de cache de prompt bien placée a réduit le coût de cette exécution d'environ 75 %. Il a aussi pointé un piège sournois : une étape de CI plus longue que la durée de vie du cache fait repartir tout le contexte au prix plein.

Quatrième thème : mesurer avant d'optimiser

Dernier point commun : personne ne défendait l'intuition. Datadog n'ajoute une compétence que si une évaluation le justifie. Alpic fait une revue collective régulière des commentaires de PR pour améliorer ses règles. Otto Group compare les solutions sur une vraie migration plutôt que sur des démos commerciales.

Ben Burtenshaw (Hugging Face) a poussé la logique jusqu'à l'entraînement, avec les environnements de reinforcement learning. Un environnement, c'est une tâche, un runtime isolé et un vérificateur. Pour du développement logiciel : un ticket, un dépôt, et des tests qui servent de signal de récompense.

Ce qui m'a plu, c'est la progression qu'il recommande, du moins coûteux au plus ambitieux :

1. évaluer les modèles existants sur ses propres tâches, et s'arrêter si c'est suffisant ;
2. améliorer le système autour du modèle : prompts, outils, harness ;
3. entraîner seulement si le gain le justifie, par distillation ou RL.

Il a aussi insisté sur la fidélité à la production : un agent qui devine qu'il est dans une simulation apprend à exploiter la simulation, pas la compétence. Hugging Face annonçait l'arrivée des environnements RL dans les dépôts de datasets du Hub, et OpenEnv comme couche d'interopérabilité.

Pas d'optimisation sans benchmark, et le benchmark, ce sont vos cas réels !

Les talks hors-piste

Trois talks sortaient un peu des thèmes récurrents d'agents et de factories.

Olivier Teboul (Gradium) a ouvert le capot de l'IA vocale. Trois secondes de parole, c'est une poignée de tokens en texte mais environ 72 000 échantillons en audio brut à 24 kHz : impossible pour un transformer en l'état. D'où les codecs neuronaux qui compressent à 12 Hz, et les transformers multi-flux qui écoutent et parlent en même temps. La seconde moitié était de l'ingénierie pure : un budget de 300 ms de bout en bout, dont un tiers mangé par un aller-retour transatlantique, et une pénurie de GPU qui oblige à multiplier fournisseurs et architectures. Leur réponse ultime : un modèle de 100 millions de paramètres qui tourne sur l'appareil, capable de cloner une voix à partir de dix secondes d'audio.

Jakob Pörschmann (Black Forest Labs) a utilisé FLUX pour générer en temps réel les frames d'un jeu vidéo, puis piloter un bras robotique avec FLUX Action, publié en open weights la veille. Au passage, une leçon très applicable : avant de fine-tuner, un simple prompt upsampling personnalisé (un LLM qui reformule la demande en y intégrant les règles de design) suffit souvent, sans aucun entraînement. Sa formule de conclusion mérite d'être retenue : une personnalisation doit être aussi spécifique que nécessaire, et aussi générale que possible.

Ben Morss (Mistral) a fait un atelier très terre à terre : faire tourner Ministral 3 14B sur un Mac de 48 Go avec MLX-LM, l'exposer en API compatible OpenAI sur localhost, et le brancher à Mistral Vibe. Il a été honnête sur les limites : la mémoire ne se résume pas aux poids (le KV cache grossit avec le contexte), et le modèle local reste moins autonome que les meilleurs modèles hébergés. Mais pour la confidentialité, le hors-ligne et des tâches simples, c'est utilisable dès aujourd'hui pour peu qu'on ait une bonne machine.

La prise de recul : deux horloges

Le talk le plus inattendu venait de Clemens Rawert, co-fondateur de Langfuse, historien de l'économie de formation. Son point de départ : des centaines de millions d'utilisateurs, des gains de productivité mesurés sur des tâches précises, et pourtant aucun boom visible dans les statistiques macroéconomiques.

L'histoire offre des précédents. La machine à vapeur a mis plus d'un siècle à peser sur la productivité. L'électrification des usines a pris 30 à 40 ans après la première centrale d'Edison, pas pour des raisons techniques, mais parce qu'il fallait repenser l'organisation des usines : passer d'un moteur central à un moteur par machine. L'ordinateur a suivi la même « courbe en J » : un ralentissement pendant la phase d'apprentissage, puis l'accélération dans les années 1990.

Sa conclusion : il y a deux horloges. Celle de l'innovation, rapide, et celle de la diffusion, lente, qui dépend des technologies complémentaires, de la réorganisation et des compétences.

Avec le recul, ce talk donnait la clé de lecture de tous les autres. Les sandboxes d'Alpic, la préparation brownfield d'Otto Group, les outils restreints de Škoda, les workflows durables de Mistral : ce sont précisément les « moteurs par machine » de notre époque. Le modèle est la centrale électrique ; ce qui manque encore, c'est le réaménagement de l'usine.

Ce que j'en retiens en tant que développeur

Je fais du PHP/Symfony depuis une douzaine d'années, et ce qui m'a le plus rassuré, c'est que les bonnes réponses ressemblent beaucoup à du "bon" génie logiciel.

1. Un tool d'agent est une API publique. Validation côté serveur, identité imposée par le contexte d'authentification, périmètre minimal, actions dangereuses séparées. Un peu comme les Voters Symfony, si on veut faire le parallèle.
2. Rendre le projet « agent-ready » est un chantier en soi. Mettre en place la documentation métier et technique, des tests, mettre à plat les conventions, etc.
3. Investir dans les specs plutôt que dans la relecture. Une heure de conception détaillée vaut mieux que trois heures à réorienter un agent sur une PR. Les ADR redeviennent un outil quotidien.
4. Garder un humain propriétaire de chaque changement.
5. Tracer et mesurer avant d'optimiser. Coût par exécution, taux de cache, tokens d'entrée par appel : sans traces, on paye sans savoir pourquoi.
6. Ajouter de la complexité seulement sur un échec observé. Un outil ou une compétence de plus peut dégrader le résultat ; Datadog en a fait l'expérience.
7. Concevoir les workflows comme des machines à états. Attendre, reprendre, s'arrêter : les cas « humain en attente » et « panne au milieu » font partie du design.

Conclusion

Je disais en intro que je ne savais pas à quoi m'attendre : eh bien, j'ai été très emballé par ces deux jours. Je dois quand même avouer qu'au début, avec ces histoires de factories, je me disais "mais en fait, on construit nous-mêmes les systèmes qui vont nous remplacer". Les différents talks ont pourtant été plutôt rassurants : même si on va tendre vers ces systèmes, l'humain reste présent dans les moments critiques, garant et responsable de ce que l'IA va faire. Pour construire et faire fonctionner ces factories, on a toujours besoin de nos compétences : conception, revues, tests, gestion des permissions, mise en place de workflows, etc., auxquelles s'ajoute une composante "business" qu'il va falloir affûter.