Tech Ready 2026 : l’IA en production, vue de l’intérieur
Le 5 juin 2026, j’ai assisté à Tech Ready, une journée de conférences autour du cloud et de l’IA.
J’en repars avec un fil rouge qui m’a traversé tout au long de la journée : plusieurs oratrices et orateurs ont insisté sur le fait que l’IA est un outil qu’il faut diriger, pas suivre, et que le code produit reste de la responsabilité du développeur. Voici mon compte-rendu de 5 talks qui m’ont particulièrement intéressé.
1. U TECH (Système U) : adopter l’IA générative dans une grande DSI
« Prise en main de GitHub Copilot & Adoption en Entreprise »
Julien Landuré et Quentin Michineau
U TECH est la DSI de la Coopérative U (Super U, Hyper U, U Express…) : 650 collaborateurs, 350 prestataires, 71 équipes produit/service/plateforme. C’est donc un SI de grande taille.
Julien et Quentin ont commencé par présenter l’évolution des workflows développeur en trois générations : workflow assisté par IA (suggestions ponctuelles), puis workflow avec complétion IA (Copilot classique), puis workflow piloté par IA avec l’émergence du mode Agent à partir de 2025. Dans un marché qui évolue vite (GitHub Copilot, Cursor, Claude, Bolt, Ghostwriter…), U TECH a structuré son adoption en 4 étapes : tester via un Beta Program, accompagner l’usage, récolter du feedback, puis généraliser et cadrer.
Les résultats du Beta Program (59 réponses) sont encourageants : 88 % estiment que leur productivité a augmenté, 58 % estiment gagner entre 30 minutes et 1 heure par jour, et 98 % recommandent l’outil. À noter aussi : 54,2 % constatent une amélioration de la qualité du code, mais 45,8 % ne le perçoivent pas, ce qui montre que le sujet de la qualité mérite d’être suivi séparément.
Sur le plan technique, la présentation aborde les limites des LLMs et les solutions associées (Context Engineering, RAG, MCP). U TECH a également créé son propre registre MCP interne, qui liste les serveurs MCP disponibles et approuvés en interne. Utile dans un écosystème où 180 nouvelles entrées MCP sont apparues en seulement 5 mois (janvier à mai 2026).
La présentation aborde aussi le Specification Driven Development : piloter l’agent par des specs formelles, avec des commandes dédiées à chaque phase du projet (/gsd-discuss-phase, /gsd-plan-phase, /gsd-execute-phase, /gsd-ship). L’idée est de donner à l’agent un cadre précis à chaque étape plutôt que de le laisser interpréter librement.
Les trois messages de clôture résument bien l’état d’esprit de ce retour d’expérience :
« Vous devez rester le pilote, l’IA le copilote. »
« Vous devez être en capacité de valider le code généré. »
« S’en servir pour apprendre et ne pas générer sans comprendre. »
2. La Poste / Thales : l’IA industrielle à grande échelle
« Quand l’IA fait le tri de manière industrialisée »
Guillaume Leblondel et Nicolas Payneau
La Poste Groupe et Thales ont présenté 6 ans de déploiement de l’IA sur le tri postal. Il ne s’agit pas d’un POC : c’est un programme industriel avec des contraintes physiques. Les chiffres donnent l’échelle : 34 modèles en production, 50 millions d’appels par jour, 150 GPU on-prem, 50 sites edge, 2 data centers sur des périmètres allant du Courrier au Bureau de Poste.
La contrainte principale de toute la présentation : les machines de tri physiques imposent une latence inférieure à 500 ms. L’IA doit s’adapter au monde physique, pas l’inverse.
Les speakers ont retracé les défis successifs rencontrés. L’architecture monolithique initiale (API + Batching + Pre/Post-Processing + Modèles sur une couche TensorFlow) fonctionnait bien, mais souffrait d’un couplage fort et d’une adhérence TensorFlow qui limitait l’évolution. La migration IaaS vers PaaS a permis de bénéficer de la scalabilité, managed services mais des difficultés sont apparus comme de la dette technique, pénurie sur les approvisionnements de GPU, wokflow validation de MEP complexe.
La dernière partie de la présentation porte sur l’orchestration agentique. L’architecture retenue place un agent Coordinateur central qui dispatche vers 6 agents spécialisés (Acquisition, Tracking, Adresse, Logs, Atlassian, GitLab). Le framework choisi est Agno (anciennement Phidata), agnostique au modèle et modulaire : chaque agent peut tourner sur un LLM différent selon la tâche, sans dépendre d’un seul fournisseur. Pour une infrastructure souveraine on-prem, c’est un point important.
La présentation se termine sur 5 questions ouvertes, sans réponse définitive : MCP ou pas ? Quelle taille de modèle selon la tâche ? vLLM ou Ollama ? Comment gérer la mémoire à court, moyen et long terme ?
3. SNCF Connect & Tech : la vie d’un chatbot après le go-live
« Industrialiser un chatbot RAG : SNCF Connect vous invite dans les coulisses post-déploiement »
Amandine Tran et Alice Calliger
La présentation retrace la trajectoire du bot CONNECT depuis 2023 : NLP d’abord, RAG ensuite, agents à partir de 2026. Mais l’essentiel du talk porte sur ce qui se passe après le déploiement initial : les 7 challenges concrets que l’équipe a rencontrés.
Chaque challenge est traité avec le même schéma : problème constaté, solution mise en place, apprentissages, évolution planifiée.
Monitoring : l’équipe a séparé les métriques business (utilité, autonomie, latence) des métriques techniques, avec des alertes classées par criticité. Apprentissage : les vues métier et technique gagnent à être différenciées.
Cycle de vie des LLM : les modèles ont changé 5 fois en un an. Sonnet 3.7 a dû être retiré à cause de problèmes de latence et de quotas. Un point intéressant soulevé : il n’est pas nécessaire de mobiliser un modèle puissant pour des questions basiques, un modèle plus léger et moins coûteux peut suffire. La gestion du cycle de vie des modèles est une vraie contrainte.
Feedback utilisateurs : 3 000 conversations sont analysées toutes les 2 heures via AlloBrain. Apprentissage : les irritants prioritaires ne sont pas forcément les plus visibles. La personnalisation des réponses (connecté/non connecté) a apporté +1,2 points de pourcentage de réponses jugées utiles.
Latence : deux optimisations ont eu un impact notable. La mise en cache des suggestions du bot a fait passer le temps de réponse de 8 secondes à 50 ms. La réduction de 30 % de la longueur des réponses a permis de gagner 3 secondes en moyenne.
Architecture : le RAG existant (LlamaIndex) n’a pas été remplacé. Il est devenu un composant d’une architecture LangGraph plus large, avec guardrails et agents spécialisés. La transition vers les agents ajoute de la complexité, notamment sur la gestion des intentions ambiguës et le routing.
Visibilité : un chatbot bien conçu mais mal exposé reste peu utilisé. L’équipe a travaillé sur des ancrages et un centre d’aide dédié dans le compte client.
Les résultats mesurés par rapport à décembre 2025 : +153 % de questions selfcare posées sur le chatbot, +6,7 points de pourcentage de réponses jugées utiles, et −5 secondes de temps de réponse moyen. Le message de clôture que j’ai retenu :
« La première mise en production n’est que la partie émergée de l’iceberg. »
4. Doctolib : l’agentic coding comme sujet de platform engineering
« L’Agentic Coding, nouveau territoire du Platform Engineering »
Julien Tanay et Yankı Sesyılmaz
Doctolib a présenté son approche de l’agentic coding sous l’angle du platform engineering : comment structurer l’adoption à l’échelle d’une organisation, plutôt que de laisser chaque développeur trouver sa propre façon d’utiliser les outils IA. En 2025, chaque équipe explorait de son côté. En 2026, ils ont fait le choix d’un outil unique (Claude), d’un mode agentic-first, et de traiter l’agent comme un contributeur à part entière.
Agentic First. Cela implique de repenser les workflows de bout en bout. Doctolib utilise le Plan Mode et le Spec-Driven Development : on décrit le quoi pas le comment, l’agent planifie et propose, le développeur valide et oriente. Les specs sont en Markdown pur, versionnées comme du code, au format OpenSpec (léger, customisable, sans vendor lock-in). Une formule résume bien ce changement :
« Le prompt engineering devient du spec engineering. »
La parallélisation des agents est gérée via les Worktrees : un espace isolé par sujet pour éviter les conflits. L’impact sur les équipes est aussi pris en compte : formation, évolution des rôles PM et designers, rituels Agile à adapter.
Plugin Marketplace. Doctolib a construit une marketplace de plugins Claude interne regroupant skills, agents, hooks et serveurs MCP, traitée comme un produit interne à part entière. Les plugins couvrent des besoins plateforme (review, télémétrie) et des besoins équipes (standups, rétros, automatisation de releases). La pratique du dogfooding est centrale : « on construit ici ce qu’on déploie ailleurs ».
Outillage Standard. Face à un écosystème qui évolue rapidement, l’équipe applique une discipline de tri : scanner, évaluer, ne garder que ce qui apporte de la valeur. Et parfois, ne rien construire du tout :
« Attendre qu’Anthropic shippe vite : ce qu’on construirait arrive souvent en natif. La valeur, c’est savoir ne pas construire. »
Remote Agents. La partie la plus avancée de la présentation : GitHub Actions est utilisé comme MVP pour orchestrer des agents distants : infrastructure déjà disponible, observabilité native, permissions gérées par GitHub, résultat sous forme de Pull Requests. Les guardrails sont organisés à trois niveaux : master prompt, skills packagées, et prompt utilisateur (« le seul degré de liberté de l’agent »).
Le cas d’usage le plus intéressant : les « standard changes », des migrations techniques répétitives et bien définies, exécutées avec très peu d’intervention humaine. Le concept de « Shift approval left » consiste à valider le pattern en amont plutôt que chaque PR individuellement. Stripe et Spotify sont cités comme exemples avec des milliers de PRs auto-générées.
La formule de clôture donne à réfléchir :
« Les agents IA ne créent pas de problèmes, ils rendent très concrets les problèmes existants. »
Autrement dit : si votre base de code manque de qualité, si vos process sont flous, si vos specs sont imprécises, un agent IA le rendra visible rapidement. La qualité du code devient un prérequis pour tirer parti des agents.
5. Florian Bruniaux : le context rot, ennemi silencieux de vos agents
« Tokens : le nouveau cloud waste »
Florian Bruniaux
Florian Bruniaux a abordé un problème que beaucoup d’utilisateurs d’agents IA rencontrent sans l’avoir formalisé : le context rot, la dégradation progressive des performances d’un agent à mesure que son contexte grossit.
D’après une étude Chroma Research portant sur 18 LLMs, la précision d’un agent passe de 99 % à 16K tokens à 50 % à 200K tokens, et cela s’observe sur tous les modèles testés.
7 sources de dégradation sont identifiées :
- CLI Output : les commandes qui injectent du texte non filtré dans le contexte
- MCP Without Filter : les serveurs MCP qui injectent leurs réponses brutes
- Response Verbosity : les réponses de l’agent trop longues par défaut
- Oversized Files : les fichiers de code trop grands injectés dans le contexte
- Config Bloat : un fichier de configuration surchargé
- Dirty History : l’historique de session non nettoyé
- Schemas in System Prompt : les schémas MCP injectés dans le system prompt
Un point intéressant de la présentation : un contexte « vide », avant même la première question, peut déjà peser entre 13 000 et 55 000+ tokens, dont 5 000 à 44 000 tokens pour les seuls schémas MCP actifs. Comme le rappelle une note sur la slide : « Chaque segment est configurable. Aucun n’est surveillé par défaut. »
Florian a conclu avec 3 actions concrètes, sans changer de modèle ni installer d’outil supplémentaire :
$ rtk gain: mesurer son waste actuel, commande par commande (RTK est un proxy CLI open source qui filtre le texte superflu produit par les commandes shell, réduisant la consommation de tokens de 60 à 90 %)$ claude mcp list: désactiver les serveurs MCP inutilisés (chaque serveur inutile représente environ 13 000 tokens)- Deux règles dans son fichier de configuration : réponse concise, pas de récapitulatif non demandé
Remarque : Florian est l’un des contributeurs de RTK, c’est toujours plaisant de rencontrer les personnes qui développe les outils que l’on utilise !
Résultat estimé avec ces trois actions combinées : ~60 % de réduction du contexte, sans changer de modèle.
Ce que je retiens de Tech Ready 2026
Tous les talks de la journée parlaient d’organisations qui ont déjà passé le stade de l’expérimentation et qui cherchent à industrialiser leur usage de l’IA. Les retours d’expérience présentés sont très intéressants et exposent les difficultés et les questions encore ouvertes.
Le message qui revient le plus souvent : l’IA amplifie ce qui existe déjà, en bien comme en mal. Une équipe avec de bonnes pratiques, des specs claires et une base de code soignée tirera davantage parti des agents. Une équipe avec de la dette technique verra cette dette rendue encore plus visible.
Ce que je retiens est que dans tous les cas, le développeur reste responsable de ce qui est produit. L’IA suggère, génère, exécute, mais c’est l’humain qui valide et qui porte la responsabilité du résultat.
