Vous rappelez-vous la dernière fois que vous avez montré votre interface à un vrai utilisateur ? Avant le premier sprint. Pendant. Ou après la mise en production ? (Les amis et la famille ne comptent pas).
Votre réponse à cette question est essentielle : elle détermine, à elle seule, si votre produit s’apprête à être adopté ou ignoré. Et qu’on se le dise, vous n’avez aucun intérêt à livrer une plateforme fantôme. À ce propos : 66 % des projets logiciels n’atteignent pas leurs objectifs selon le célèbre Standish Group dans son Chaos Report de 2020.
Et on vous arrête tout de suite. Le code n’y est pour rien, tout comme les délais. Le vrai problème provient du prototypage et de la validation utilisateur qui n’a pas été réalisé au bon moment. Alors prêt à changer tout cela ? C’est parti pour notre premier épisode sur le Design Driven Development.
C’est bien connu le design c’est fait pour faire joli. Oui, enfin à faire joli mais surtout à convertir. Et si cela semble clair comme de l’eau de roche, au sein des opens space des organisations, tout n’est pas toujours aussi simple.
Vous connaissez déjà le schéma. Les équipes business émettent un besoin sous forme de cahier des charges. Les équipes tech reçoivent alors le document. Chacun bien installé dans son couloir. Et le design arrive en bout de chaîne, une fois que les décisions structurantes ont été prises. Voilà comment une décision primordiale est transformée en simple décoration.
« La culture française a toujours mis une barrière entre le business et l’exécution technique, ne laissant que très peu d'échanges entre ces deux mondes. Cet ancrage culturel conduit inéluctablement à la réalisation de solutions techniques qui ne répondent pas aux besoins des utilisateurs finaux. »
Résultat : vous livrez des produits techniquement solides, livrés dans les délais et conformes au cahier des charges, mais que personne n’utilise.
Soyez rassurés, ce phénomène toucherait près de 50 000 projets dans le monde, selon le Standish Group. De quoi vous sentir moins seuls et vous rappeler que l’erreur est humaine tout comme l’itération. Mais alors comment expliquer ce nombre d’échecs à travers le globe ?
Le premier facteur de réussite d’un projet IT repose avant tout dans le soutien apporté par la direction. Avant la clarté des besoins, il est essentiel d’impliquer des utilisateurs dans le processus de création. C’est la variable qui change tout pour vos projets.
Et ça n’a rien à voir avec un potentiel problème de compétence ou de budget. C’est tout simplement un problème d’ordre et de priorisation. Il suffit de faire intervenir le design au commencement pour qu’il garde sa faculté décisionnelle.
Voici un point important avant de continuer notre récit. Le sigle DDD peut désigner deux approches radicalement différentes. Le Design Driven Development et le Domain Driven Design. Pas de panique, on vous explique leurs différences dans un petit tableau comparatif.
Pensez à y prêter quelques minutes de votre temps. Si vous étiez amenés à les confondre dans un brief, cela pourrait orienter vos décisions d’architecture vers la mauvaise direction. Et cà clairement personne n’a envie d’y penser.
| Critère | Design Driven Development | Domain Driven Design |
|---|---|---|
| Priorité | L'expérience utilisateur (UX First) | La modélisation du domaine métier |
| Outil central | Figma, prototypage, wireframe, design system | Event storming, langage ubiquitaire |
| Question clé | Comment l'utilisateur vit l'interface ? | Comment le métier structure les données ? |
| Livrable | Wireframes, mockups, prototypes, handoff | Cartes de contexte, diagrammes d'entités |
| Équipes | Designers, devs front-end, UX researchers, Product Owner | Architectes, devs back-end, experts métier |
| Méthodologie | Itérations design–test–dev, prototypage rapide, handoff structuré | Event storming, context mapping, repositories |
| Point de départ | La maquette et le parcours utilisateur | Le modèle de domaine et les règles métier |
| Cas d'usage | Apps mobile, e-commerce, interfaces client, SaaS B2B | ERP, systèmes complexes, microservices, logiciels métier |
| Compatibilité | Agile, Lean UX, Design Thinking, Scrum | Agile, microservices, architecture hexagonale, CQRS |
À noter : Le Domain Driven Design et le Design Driven Development sont des méthodes différentes mais complémentaires. En effet, un projet peut tout à fait adopter le DDD D’Evans pour construire son architecture backend et le Design Driven Development pour ses interfaces. C’est d’ailleurs souvent la compilation des deux qui crée l'optimisation ultime des projets de logiciels sur-mesure complexes.
Le Design Driven Development est une approche qui permet de structurer le design et l’expérience utilisateur ensemble au cours du cycle de développement. La recherche utilisateur, le prototypage et la validation des parcours précède toutes les décisions techniques. Avant le premier sprint et le premier commit.
Née d’une convergence entre les méthodes agiles, le design thinking et Lean UX, le DDD ne rajoute aucune couche supplémentaire au processus projet. Il en change seulement l’ordre pour placer l’utilisateur au point de départ des interrogations.
Le Design Driven Development est une méthode efficace pour changer la manière dont les équipes prennent leurs décisions. Chacun des principes que nous allons vous présenter est un choix organisationnel avec un impact concret sur vos projets logiciels.
Ici, les questions à se poser sont simples : qu’est-ce que l’utilisateur doit accomplir ? Qu’est-ce qui le freine dans sa navigation ? Comment agit-il aujourd’hui sur l’interface ? Répondre à ces interrogations avec un échantillon de vos utilisateurs finaux vous permet de définir les processus techniques à mettre en place.
Ce que cela change pour les organisations :
On sait que vous l’avez déjà compris. Mais parfois c’est pas plus mal de se répéter. Il est essentiel de construire un prototype rapide et interactif pour simuler les flux, tester les parcours et révéler les frictions. De quoi faire de votre wireframe mockup un outil de décision avant même d’avoir écrit la moindre ligne de code.
«Tester avec 5 utilisateur suffit à révéler 85 % des problèmes d'usabilité. Les organisations qui investissent dans le prototypage UX en phase de conception réduisent leurs cycles de développement de 33 à 50 %. »
Ce que cela change pour les organisations :
« Les développeurs passent en moyenne 50 % de leur temps sur du rework qui aurait pu être évité. Un Handoff structuré et un prototypage préalable coupent ce gaspillage à la source. »
Chaque retour utilisateurs alimentent l’ensemble du cycle de conception et de développement. Ainsi, aucun sprint ne démarre sans validation de la phase précédente.
Ce que cela change pour les organisations :
Avec l’approche Design Driven Development, les designers et les développeurs partagent le même référentiel : composants, tokens, typographies et espacement. Le tout, documenté, versionné et surtout réutilisable.
Ce qui permet de traduire ce que Figma définit en code implémenté. Sans interprétation. Pour un Handoff fluidifié grâce à un référentiel ou « source of truth » commun (source de vérité partagée).
Ce que cela change pour les organisations :
Enfin, la méthode de l’itération issue de la culture Agile permet de mesurer l’écart entre le design et la réalité d’usage. Ce qui aide l’ensemble des équipes projet de corriger et d’optimiser le produit en évitant une dette fonctionnelle. C’est l’itération continue (l’amélioration) qui contribue au projet de vivre et de s’adapter constamment vers un mieux pour l’utilisateur.
Ce que cela change pour les organisations :
Le design process du DDD (Design Driven Development) produit des résultats mesurables. Les développeurs récupèrent en moyenne 50 % du temps perdu sur du rework évitable grâce à un prototypage et un handoff structuré. (Amazon AWS).
Mieux encore :
Chez toHero, le Design Driven Development est notre approche de travail sur chaque projet qui touche de près ou de loin une interface. UX/UI et direction artistique, Application mobile en
React-Native, plateforme e-commerce et marketplace ou solution métier sur-mesure.
La même équipe pense le parcours, construit le prototype, structure le design system et accompagne les développeurs jusqu’au handoff. Ainsi, il n’y a plus aucune perte de sens entre la maquette imaginée et le code livré.
Nos références couvrent des projets d’envergure en e-commerce multimarque, en application mobile et en intégration ERP / PIM. Sur chacune de nos références, le prototypage et les tests utilisateurs précèdent toujours le premier sprint.
Mais, le Design Driven Development seul ne suffit pas. Il doit impérativement répondre à la question :
« Comment construire ?».
Encore faut-il savoir ce que l’on cherche à construire. Et c’est là que la plupart des se projets se trompent dès le cadrage.
C’est vrai ça, c’est quoi au final la question la plus importante dans la création d’un produit logiciel ?
5 tests utilisateur sur prototype suffisent à révéler la quasi-totalité des problèmes d’usabilité d’une interface. Un sprint de développement sans cette validation les crée. Le choix est simple.
Construire quelque chose qui fonctionne. Construire quelque chose que les gens aiment. Ce sont deux ambitions différentes. Avec des critères de succès différents.
C’est précisément à qu’interviennent le MVP et le MLP. Deux acronymes pour deux philosophies opposées en terme de construction produit. L’un répond à la question du risque budgétaire, l’autre répond à la question de l’adoption.
Dans l’épisode 2 de notre série sur le Design Driven Developement, nous explorons pourquoi toHero a tourné le dos au Minimum Viable Product pour lui préférer le Lovable Product. Une approche qui change la question dès le cadrage.
À bientôt pour de nouvelles aventures numériques !
Le Handoff correspond à la phase de transmission entre designer et développeur. Il comprend les assets exportés au bon format, les annotations d’interactions, les états des composants, les breakpoint responsive et les tokens du design system. Dans une approche Design Driven Development, l’outil Figma joue le rôle de source of truth. C’est-à-dire la source de vérité qui fait que ce que le designer définit, le développeur l’implémente sans interprétation. Un handoff mal structuré est la première cause d’écart entre ce qui a été conçu et ce qui est livré. Et c’est ici que la majorité des projets perdent la qualité de l’intention design.
Un wireframe mockup est une représentation statistique basse fidélité de l’interface. Il valide la structure et les flux de navigation, sans entrer dans le détail visuel. Un prototypage interactif est quant à lui une simulation des comportements des composants, des transitions entre écrans et des parcours utilisateurs complets. Dans le DDD, le deux interviennent à des étapes différentes. Le wireframe en phase d’idéation pour valider la structure et le prototype avant le développement pour valider l’expérience. Les deux sont indissociables pour valider complètement le projet.
L’itération est le moteur du DDD. Via le double-track Agile, une piste design travaille à un deux sprints en avance sur la piste développement. Les équipes de développement disposent toujours de spécifications design validées à chaque sprint. Sans bloquer la cadence de livraison. Chaque sprint mesure l’écart entre l’intention design et la réalité d’usage pour corriger avant qu’il ne devienne une dette fonctionnelle. L’itération continue est ce qui distingue un projet DDD d’un projet qui livre une vision figée.
Avec les chiffres. 85 % des fonctionnalités livrées sont rarement ou jamais utilisées selon le Standish Group. Les organisations qui investissent dans le prototypage UX réduisent leurs cycles de développement de 33 à 50 %(Nielsen Norman Group). Forrester estime de son côté, le ROI moyen d’un investissement UX jusqu’à 9 900 %. Des arguments implacables pour les DSI et les directeurs financiers.
88 % des transformations échouent sur l’adoption (Bain, 2024). Voici comment toHero utilise le design thinking pour remplacer le MVP par le Minimum Lovable Product et ce que ça change
66 % des projets IT échouent. Pas à cause du code. À cause d’interfaces que personne n’a testées avant de les construire. Découvrez comment le Design Driven Development et le prototypage changent
Agentic RAG, orchestration des agents IA, conformité réglementaire et AI Act : comment industrialiser l’agentique dans le développement logiciel sur mesure. Épisode 2.
Dans le premier épisode de cette série sur les nouveaux paradigmes de la production logicielle, nous avons posés les fondations : ce qu’est l’agentique. Nous avons étudié comment l’agentic code transforme le développement logiciel sur mesure, et pourquoi les gains de productivité observé chez Rakuten, TELUS ou dans les études BCG et McKinsey ne sont plus de l’ordre de la promesse mais du constat.
Cependant une question est resté ouverte : si les agents IA sont aussi puissants, pourquoi si peu d’organisations arrivent à l’industrialiser ? Pourquoi l’écart entre expérimentation et création de valeur reste-t-il aussi large ?
La réponse tient en trois défis que nous allons explorer dans ce deuxième épisode. Parmi ces enjeux, l’on retrouve : la gestion du contexte technique et le rôle de l’agentic RAG, la transformation organisationnelle nécessaire pour orchestrer et mesurer ces systèmes et la conformité réglementaire avec l’AI Act Européen. Trois sujets qui, mis bout à bout, dessinent la feuille de route de l‘industrialisation agentique pour les DSI, CTO et directions métiers.
Voici un défi que peu de décideurs anticipent, et pourtant c’est l’un des plus critiques : la gestion du contexte technique. Dans un projet logiciel réel, les informations utiles sont éparpillées partout : dépôt de code, documentation technique, historique des commits, tickets de maintenance.
Comment un agent IA peut-il trouver la bonne information, au bon moment, sans se noyer dans le bruit ?
C’est exactement ce que résout l’agentic RAG. RAG, c’est l’abréviation de Retrieval-Augmented-Generation, en français « génération augmentée par la récupération d’informations ». Le principe est simple : au lieu de travailler uniquement depuis ce qu’il « sait » (ses données d’entraînement), l’agent IA va chercher de l’information ciblée dans des sources externes (repository, documentation, bases de connaissance) avant d’agir. C’est la différence entre un consultant qui répond de mémoire et un consultant qui consulte vos documents internes avant de vous conseiller.
La recherche « Deep Code : Open Agentic Coding » publié sur ArXiv identifie un conflit fondamental entre surcharge d’information et goulot d’étranglement du contexte des IA LLM, et propose une orchestration combinant compression de source, indexation en mémoire, injection conditionnelle via agentic RAG, et correction en boucle.
« Les méthodes actuelles font face à un conflit fondamental entre surcharge d'information et goulot d'étranglement du contexte des LLM. »
Et l’enjeu est encore plus critique sur le code legacy : des systèmes construits sur des années, avec des couches de règles implicites, des dépendances invisible et des arbitrages historiques que plus personne ne documente. Chez toHero, nous rencontrons régulièrement ces situations dans nos projets de développement web. Sur ces bases, l’agentic RAG devient un véritable garde-fou : il aide l’agent IA à travailler avec le bon contexte (et pas juste un contexte « copié-collé »), ce qui réduit le risque d’erreurs et facilite une modernisation progressive, plus contrôlée.
Si pour toutes ces raisons les systèmes agentiques suscite un intérêt grandissant, un écart béant se creuse entre ceux qui expérimentent et ceux qui créent de la valeur. McKinsey estime que près de deux entreprises sur trois testent déjà des agents IA. Mais à peine un quart d’entre elle les déploiement à l’échelle.
Et selon BCG, le chiffre le plus révélateur est peut-être celui ci : 5 % des entreprises génèrent aujourd’hui une valeur mesurable depuis l’IA.
Et c’est d’un logique implacable : intégrer un agent IA, ce n’est pas comme installer un plugin. Cela touche à la gouvernance, aux responsabilités, à l’intégration outillée, à la sécurité et à la mesure de performance. C’est d’abord une transformation organisationnelle avant d’être une transformation technologique.
« Aujourd'hui, l'IA est greffée en périphérie. Pour produire un impact réel, elle doit être intégrée aux processus fondamentaux et devenir un catalyseur de transformation. »
L’orchestration, c’est le nerf de la guerre. Concrètement, c’est la capacité à définir ce qui est automatisable, ce qui nécessite une validation humaine, et surtout comment les agents interagissent entre eux.
Imaginez cette mise en situation : un chef de projet distribue le travail entre plusieurs développeurs spécialisés, sauf que ces développeurs sont des agents IA. L’enjeu n’est pas technologique : il est organisationnel.
Anthropic souligne d’ailleurs qu’au delà de 10 outils ou 10 000 tokens de définitions, des mécanismes de sélection et de contrôle sont indispensables pour garder un système exploitable. Et son rapport 2026 identifie quatre priorités stratégiques pour les organisations :
La supervision ne disparaît donc pas. Elle se repositionne sur les zones critiques. Et c’est précisément cette capacité d’orchestration que nous développons chez toHero à travers notre méthodologie Delivery Management Guru.
Piloter des projets avec rigueur opérationnelle, anticiper les risques et maintenir une gouvernance continue, y compris quand une partie du travail est exécutée par des agents.
Autre enjeu à fort impact : mesurer la valeur. Sans indicateur clairs, impossible de piloter correctement un projet. Mais alors quels sont les indicateurs à suivre ?
A ce propos, BCG observe d’ailleurs un signal intéressant : la part des agents IA dans la valeur IA totale des entreprise a presque doublé en trois ans, passant de 17 % en 2025 à une projection de 29 % d’ici 2028. Pour les DSI et CTO, c’est une tendance impossible à ignorer dans la construction de leur feuille de route.
Au-delà de l’automatisation IA des tâches, l’agentique introduit progressivement une nouvelle couche dans les architectures numériques. Les agents IA ne remplacent pas les architectures logicielles existantes. Ils viennent s’y superposer comme une couche d’orchestration capable de piloter services, API et outils techniques, déjà en place. La différence clé avec l’automatisation classique repose sur le fait que les agents interprètent un objectif et décident eux-mêmes de la séquence d’action nécessaire pour y parvenir
Pour les organisations qui développent des plateformes numériques ou des applications métiers sur-mesure, cette nouvelle couche ouvre des perspectives majeures. Elle permet d’envisager des architectures où les agents assistent les équipes techniques dans la supervision, l’analyse ou l’évolution des systèmes existants.
Autre point incontournable dans l’usage de l’IA : la conformité réglementaire. En Europe, l’AI Act entré en vigueur en août 2024 encadre progressivement le développement et l’usage des systèmes d’IA. Les obligations de transparence (Article 50) et les règles relatives aux systèmes à haut risque s’appliqueront dès août 2026. Pour les organisations qui développent des logiciels, cela implique une idée simple mais essentielle : la gouvernance IA ne peut pas être ajoutée à la fin. Elle doit être pensée dès la phase de conception, surtout quand l’IA influence des décisions ou manipule des données sensibles.
Le sujet n’est pas théorique. Dans un environnement de développement logiciel (SDLC), toute modification générée par une agent IA doit pouvoir être examinée, validée ou rejetée par un humain. Et ses actions doivent être traçables : le quoi, quand, pourquoi, avec avec quelles sources.
L’objectif : que la responsabilité juridique reste clairement attribuable et que la fiabilité du système soit démontrable.
Anthropic le confirme dans son rapport : même quand l’IA est utilisé dans 60 % du travail, les développeurs maintiennent une supervision active sur 80 à 100 % des tâches déléguées.
Ce n’est pas un frein, c’est le modèle opérationnel cible.
Avec toutes ces réglementations, la conformité réglementaire peut sembler contraignante, voire limitante. Mais en réalité, c’est un formidable levier de confiance. Dans un contexte où l’IA devient une composante active de l’architecture logicielle, la conformité n’est pas un « petit plus ». C’est une condition d’adoption à grande échelle. C’est aussi ce qui différencie les organisations qui expérimentent de celles qui industrialisent durablement.
Et c’est un terrain où les acteurs européens de l’IT ont une carte à jouer : comprendre les exigences réglementaires et les intégrer dès la conception des architectures logicielles.
En comprenant l’ampleur de ces défis, il apparaît essentiel pour les organisations du numérique de saisir le train en marche. Pas pour faire comme tout le monde, mais pour transformer l’IA en facteur de compétitivité. L’agentique ne remplacera pas les équipes techniques. Mais elle réduit les délais et libère les développeurs pour l’architecture logicielle, la conception fonctionnelle et la qualité globale.
L’agentique est par ailleurs une occasion essentielle pour moderniser l’existant. Beaucoup d’entreprises ont des systèmes numériques vieillissants basés sur du code legacy.
L’exemple BCG d’une analyse multi-agents sur 3,1 millions de lignes, réduisant l’effort de 7 500 heures à une centaine d’heures, montre comment objectiver les risques et moderniser progressivement sans repartir à zéro.
Au-delà des gains de productivité, l’agentique représente un levier stratégique à plus d’un sens. D’abord pour sa capacité à automatiser davantage de tâches récurrentes, mais aussi dans sa structure qui permet de conserver une supervision humaine, de sécuriser la qualité et d’industrialiser des workflows plus fluides.
BCG rapporte ainsi que 90 % des CEOs s’attendent déjà à un ROI mesurable des agents IA dès 2026. L’enjeu maintenant est de réussir à construire une trajectoire d’adoption réaliste, conforme et mesurable.
« L'âge de l'IA agentique est arrivé. Les agents IA représentent une opportunité de plusieurs milliers de milliards de dollars. »
L’agentique marque une nouvelle étape dans l’évolution de l’intelligence artificielle appliquée aux environnements logiciels. En permettant aux système d’IA d’interagir avec des outils techniques, d’analyser des architectures et d’exécuter des actions concrètes, les agents transforment progressivement la manière dont les organisations conçoivent, développent et maintiennent leurs systèmes numériques.
Cette transformation ne repose pas uniquement sur des progrès technologiques. Elle s’inscrit dans une évolution plus profonde des organisations, de leurs méthodes de travail, de leur gouvernance et de leur architecture logicielle. Les entreprises qui sauront structurer leur stratégie technologique autour de ces nouveaux modèles d’orchestration disposeront d’un avantages décisif.
Chez toHero, nous en sommes convaincus : l’agentique n’est pas seulement une innovation technique. Elle constitue déjà l’un des leviers qui façonneront les architectures logicielles et les organisations numériques de demain. Et c’est précisément dans cette capacité d’intégration que réside l’un des enjeux majeurs du développement logiciel sur mesure.
Vous souhaitez évaluer comment l’agentique peut transformer vos projets logiciels ? Nos équipes accompagnent les DSI et Directions métiers dans la conception d’architectures prêtes pour l’ère agentique.
RAG signifie Retrieval-Augmented Generation. En version classique, un RAG enrichit les réponses d’un modèle IA avec des documents de référence. En version agentique, le RAG devient proactif : c’est l’agent IA lui-même qui décide quelles information aller chercher, dans quelles sources et à quel moment de sa tâche. C’est une brique essentielle pour travailler sur des projets logiciels complexes où le contexte est dispersé.
Parce que l’intégration des agents IA ne se limite plus à un choix technologique. Elle implique de repenser la gouvernance, les responsabilités et les indicateurs de performance. BCG estime que seule 5 % des entreprises génèrent aujourd’hui une valeur mesurable depuis l’IA.
L’AI Act, entré en vigueur en août 2024, impose des obligations de transparence et de traçabilité aux systèmes d’IA, notamment ceux à haut risque. Dès août 2026, toute modification générée par un agent IA devra être examinable, validable et traçable. La gouvernance IA doit ainsi être pensée dès la conception et non ajoutée à la fin du processus de développement.
Les indicateurs clés incluent la vitesse du delivery, la réduction des erreurs, la couverture des tests, la stabilité en production et le temps économisé sur les tâches répétitives. BCG note que la part des agents dans la valeur IA totale passe de 17 % en 2025 à 29 % projeté en 2028.
Au contraire. La conformité réglementaire est un levier de confiance. Elle différencie les organisations qui expérimentent de celle qui industrialisent durablement. Les acteurs européens du développement logiciel sur-mesure ont un avantage s’ils intègrent les exigences réglementaires dès la conception.
L’épisode 1 couvre les fondamentaux de l’agentique : l’agentic code, les architectures multi-agents et l’impact sur le cycle de vie projet. Il est disponible dans la rubrique «Les nouveaux paradigme de la production logicielle» sur notre blog.
88 % des transformations échouent sur l’adoption (Bain, 2024). Voici comment toHero utilise le design thinking pour remplacer le MVP par le Minimum
66 % des projets IT échouent. Pas à cause du code. À cause d’interfaces que personne n’a testées avant de les construire. Découvrez comment le
Agentic RAG, orchestration des agents IA, conformité réglementaire et AI Act : comment industrialiser l’agentique dans le développement logiciel sur mesure. Épisode 2.
Depuis le début des années 2020, l’intelligence artificielle s’est imposé progressivement dans les usages numériques. Les modèles de langage de grande taille, les fameux LLM (Large Language Model) comme ChatGPT, Gemini ou Claude ont transformé la génération de texte, de code et de contenus. Dans un premier temps, ces technologies ont surtout servi d’assistants capables d’accélérer certaines tâches, notamment dans les métiers du développement logiciel sur mesure.
Génération de fonctions, correction de bugs, documentation, les gains ont été immédiats.
Mais aujourd’hui une nouvelle évolution change la donne : l’agentique. Les modèles IA ne se limitent plus à produire du contenu à la demande. Ils deviennent capable d’analyser un objectif, de planifier des actions et d’interargir avec des outils techniques dans un environnement réel.
Concrètement ? On passe ainsi d’un modèle qui répond à une question, à un agent IA qui prend en charge une mission de bout en bout.
Anthropic résume d’ailleurs bien cette bascule dans son rapport 2026 Agentic Coding Trends :
« Le développement logiciel passe d'une activité centré sur l'écriture de code à une activité fondée sur l'orchestration d'agents qui écrivent du code, tout en maintenant le jugement humain, la supervision et la collaboration qui garantissent la qualité. »
Dans cet article, nous analysons ce que recouvre cette évolution et en quoi elle transforme le développement logiciel sur mesure. Chez toHero, nous accompagnons au quotidien des DSI, des CTO et des Direction Métiers sur la conception et l’évolution de leurs plateformes numérique. Et ce que nous observons sur le terrain confirment ce que disent les rapports : l’agentique n’est pas un simple gadget de plus. C’est un nouveau standard de construction.
Les éditeurs d’IA ne promettent plus simplement un « meilleure code ». Ils structurent désormais leurs offres autour d’agents capables de mener un travail long, itératif, avec outils et exécution. OpenAI présente GPT-5.3-Codex comme un modèle IA de codage agentique, 25 % fois plus rapide et conçu pour des tâches de longue durée, impliquant l’utilisation d’outils. Google formalise la même trajectoire avec Gemini Code Assist en mode agent, dans lequel le prompt est envoyé avec une liste d’outils dans un boucle actions-évaluations continue.
Anthropic dans son rapport 2026, pose un constat qui devrait interpeller toutes les directions techniques :
« Les développeurs utilisent désormais l'IA dans environ 60 % de leur travail, mais ne peuvent pleinement déléguer que 0 à 20 % de leurs tâches. L'IA est un collaborateur permanent, mais l'utiliser efficacement nécessite une préparation, une supervision active, une validation et un jugement humain. »
Autrement dit : l’IA n’est pas un remplaçant. C’est un partenaire exigeant. Et c’est un constat qui éclaire tout le reste : la valeur de l’agentique ne se joue pas dans la puissance brute des modèles IA, mais dans la capacité des organisations à orchestrer cette collaboration.
Ce qui est frappant, c’est que les grands cabinet de conseils arrivent exactement au même constat. McKinsey note que 71 % des organisations utilisent l‘IA générative, mais la plupart ne l’ont pas encore intégrée assez profondément pour en tirer des bénéfices à l’échelle.
BCG observe de son côté que la valeur IA dans la fonction tech à doublé en un an, passant de 7 % en 2024 à 13 % en 2025. Le constat est donc clair : la technologie avance plus vite que les organisations ne se transforment.
C’est pourquoi, à toHero, nous avons décidé de vous proposer cette analyse des systèmes agentiques. L’objectif étant de mieux comprendre ensemble les défis que cette innovation soulèvent et pourquoi elle redéfinit la manière dont on construit, maintient et fait évoluer le développement logiciel sur mesure.
Rappelons le point de départ. Les premiers outils d’IA dans le développement logiciel, reposaient sur des IA LLM (Large Language Model). Le principe était simple : vous posiez une question, le modèle produisait une réponse. Rapide, utile mais limité. Ces modèles ne pouvaient pas tenir un projet dans la durée, gérer les dépendances entre fichier, ni itérer jusqu’à stabiliser une modification.
Imaginez un développeur brillant mais amnésique : il vous écrit une fonction parfaite, mais il a oublié tout le reste du projet. C’était un peu l’idée des premiers modèles d’IA.
Alors, les éditeurs IA ont crée l’agentique, qui fait aujourd’hui toute la différence. Non pas comme un modèle LLM plus fort, mais comme une IA associée à un véritable environnement d’actions qui peut :
Et recommencer. C’est là qu’intervient le passage du conseil à l’exécution.
Comment tout cela fonctionne concrètement ? Les éditeur d’IA associent désormais un modèle IA à des outils embarqués dans un mécanisme d’orchestration. Pensez à un chef de projet numérique : il reçoit un objectif, décompose le travail en étape, sollicite les bons outils au bon moment et boucle jusqu’à que le résultat soit validé.
Google décrit précisément ce fonctionnement dans Gemini Code Assist : le prompt est envoyé avec une liste d’outils disponibles, et ce cycle action-évaluation se poursuit jusqu’à la complétion de la tâche. OpenAI fait de même avec son modèle GPT-5.3-Codex. Et l’écosystème suit.
Dans un blog développeurs dédié à Gemini 3, Google met en avant une intégration native avec les principaux frameworks open source d’agents (LangChain, Vercel AI SDK, LlamaIndex). Signe que l’agentique n’est plus un concept de laboratoire mais bien un standard industriel en construction.
Anthropic à même poussé cette logique encore plus loin avec le Model Context Protocol (MCP). En termes simple, le MCP est un protocole ouvert qui standardise la manière dont les agents interagissent avec les outils externes (terminal, fichiers, API, bases de donnés). Le tout, dans un cadre structuré et traçable.
Mais attention, cette puissance à un coût : leur équipe engineering signale avoir observé des configurations dans lesquelles les définitions d’outils peuvent consommer jusqu’à 134 000 tokens. Pour vous donner un ordre d’idée, c’est l’équivalant d’environ 100 pages de texte généré avant même le début de la conversation. Un vrai défi donc, de conception qui impose de repenser la gestion du contexte.
« Nous évoluons d'outils d'IA générative basés sur la connaissance vers des agents capables d'exécuter des workflows complexes dans un environnement numérique. La technologie passe de la pensée à l'action. »
Et si un agent IA, c’est bien, imaginez une équipe coordonnée d’agents. C’est la montée des architectures multi-agents : plusieurs agents IA spécialisés collaborent sur une même tâche. Un premier agent agit sur le code, un deuxième sur les tests, un troisième sur la vérification. Un peu comme une équipe agile, mais automatisée. Anthropic anticipe clairement cette évolution :
« Les systèmes mono-agent cèdent la place à des workflows multi-agents : les organisations adoptent des architectures qui maximisent les gains grâce au raisonnement parallèle sur des fenêtre de contexte séparées. »
Les chiffres suivent. Mordor Intelligence estime que ces architectures représenteraient déjà 53 % du marché agentique en 2025. Gartner prévoit que 40 % des applications d’entreprise intégreront des agents IA spécifiques d’ici fin 2026. Contre moins de 5 % en 2025. L’accélération est vertigineuse.
Un générateur de code, aussi performant soit-il, ne fait que produire du texte. Il n’intègre pas son code au projet, ne lance pas de tests et ne vérifie pas que tout fonctionne ensemble. C’est pour cela que l’on a longtemps parlé d’assistants, et non d’agents IA.
Depuis 2025, l’agentic code change la donne. L’agent IA peut analyser un projet, modifier plusieurs fichiers, lancer des tests et vérifier automatiquement si les changements fonctionnent.
OpenAI présente GPT-5.3-Codex comme un modèle IA conçu pour l’ensemble du cycle de vie logiciel (le fameux SDLC : Software Development Life Cycle) de la conception au déploiement.
Chez Rakuten, Claude Code d’Anthropic a implémenté une fonctionnalité complexe sur une base de 12,5 millions de lignes de code, en 7 heures de travail autonome, avec une précision de 99,9 %.
7 heures. Sur 12,5 millions de lignes. Sans intervention humaine pendant l’exécution. C’est le genre de cas qui illustre parfaitement ce que l’agentic code peut rendre possible.
« L'IA agentique n'est pas une étape incrémentale. C'est le fondement du modèle opérationnelle de la nouvelle génération. »
L’automatisation IA ne repose plus sur des scripts figés qu’on exécute en boucle. Les systèmes agentiques s’adaptent au contexte complet d’un projet : ils comprennent l’architecture, détectent les dépendances, et ajustent leurs actions en conséquence. La valeur ne vient plus du code généré mais du workflow automatisé, de bout en bout.
McKinsey observe une réduction des cycles de relecture de 20 à 60 %, tout en rendant la vérification plus transparente puisque les agents démontrent leur travail.
De son côté, BCG mesure un gain de productivité de 25 % sur le SDLC, avec un projection à 44 % à pleine échelle. Mais le plus intéressant vient d’Anthropic :
« Environ 27 % du travail assisté par IA porte sur des tâches qui n'auraient pas été réalisées autrement : projet de mise à l'échelle, outils internes pratiques, et travaux exploratoires qui ne seraient pas rentables s'ils étaient faits manuellement. »
C’est un point clé : l’agentique ne fait pas qu’accélérer ce que l’on faisait déjà. Elle permet de faire ce que l’on ne pouvait tout simplement pas faire. Et c’est là que la création de valeur devient massive.
Le cycle de vie projet d’un logiciel suit classiquement une logique séquentielle bien connue :
Ce cadre a permis de structurer efficacement la création de logiciel sur-mesure pendant des années, notamment pour les solutions métiers et les plateformes e-commerce complexes. Mais il atteint son seuil dès que les cycles de livraisons doivent s’accélérer ou que les équipes doivent gérer de grosses bases de code.
L’agentique introduit une rupture : les agents IA interviennent sur plusieurs étapes à la fois et itèrent bien plus vite entre les « je change » et les « je valide ».
Anthropic va même plus loin dans ses prédictions :
« L'horizon des tâches s'étend de quelques minutes à plusieurs jours : les agents passent de tâches ponctuelle à un travail autonome sur des périodes étendues, construisant et testant des applications entières. »
BCG illustre ce potentiel avec un cas frappant : une institution a cartographié les règles métiers sur 3,1 million de lignes de code legacy via une découverte multi-agents. Résultat : 5000 règles extraites en 3 semaines. 225 fois plus rapide qu’une analyse manuelle en passant de 7 500 heures à environ une centaine. Bref, tout ce qui ralentit les équipes quand la complexité augmente, l’agentique l’accélère.
Qu’est-ce que ca change concrètement pour les organisations qui font du développement logiciel ? beaucoup. Les équipes ne disparaissent plus. Au contraire, leur rôle se déplace vers des tâches à plus forte valeur ajoutée :
TELUS en est un bon exemple : l’entreprise a créé plus de 13 000 solutions IA et livré du code 30 % plus vite en accumulant 500 000 heures économisées au total.
C’est exactement ce que nous observons chez toHero dans nos projets de création de logiciel sur-mesure : les agents ne remplacent pas le delivery, ils l’accélèrent.
Nos équipes utilisent déjà des orchestrations d’agents IA pour épauler les escouades sur des tâches chronophages mais critiques : l’assistance de revue de code, l’accompagnement à la recette, une partie des développements et les phases de non-régression.
Les résultats sont concrets et mesurables. Et ce n’est que le début.
Dans le prochain épisode de cette série, nous aborderons les défis qui restent à aborder : la gestion du contexte technique avec l’agentic RAG, l’orchestration organisationnelle, la conformité réglementaire avec l’AI Act. Sans oublier les différentes stratégies d’intégrations avec leurs avantages et leurs inconvénients.
En attendant, n’hésitez pas à nous solliciter si vous souhaitez accélérer vos développements en utilisant notre méthodologie agentique.
L’agentique désigne une évolution de l’intelligence artificielle où les modèles IA ne se contentent plus de générer du contenu. Ils deviennent capables d’agir dans un environnement technique réel : analyser un projet, planifier des actions, utiliser des outils et itérer en continu, jusqu’à atteindre un objectif défini.
Un générateur produit du code à partir d’instructions. Mais il n’intègre rien au projet et ne vérifie pas le résultat. L’agentic code désigne un système capable d’agir dans un environnement logiciel : analyser un projet, modifier des fichiers, lancer des tests, vérifier les résultats et itérer jusqu’à que tout fonctionne. C’est la différence entre un conseil et une exécution.
Non. Anthropic note dans son rapport 2026 que les développeurs ne délèguent pleinement que 0 à 20 % de leurs tâches. L’IA est un collaborateur permanent même quand elle est utilisé à 60 % dans les tâches de travail. Le rôle humain reste central pour l’architecture, la conception, la supervision et la qualité. C’est à dire, des tâches à plus forte valeur ajoutée.
Le MCP est un protocole ouvert qui standardise les interactions entre agents IA et outils externes (terminal, fichiers, API, bases de données). Il permet aux agents IA de travailler dans un cadre structuré et traçable. C’est l’une des briques clés de l’architecture agentique.
L’épisode 2 abordera l’agentic RAG et la gestion du contexte technique. Vous y découvrirez la transformation des organisations (orchestration, supervision, mesure de la valeur) ainsi que la conformité réglementaire avec l’AI Act européen. Enfin nous analyserons ensemble les stratégies d’intégration concrètes de l’agentique pour le développement logiciel sur mesure.
88 % des transformations échouent sur l’adoption (Bain, 2024). Voici comment toHero utilise le design thinking pour remplacer le MVP par le Minimum Lovable Product et ce que ça change
66 % des projets IT échouent. Pas à cause du code. À cause d’interfaces que personne n’a testées avant de les construire. Découvrez comment le Design Driven Development et le prototypage changent
Agentic RAG, orchestration des agents IA, conformité réglementaire et AI Act : comment industrialiser l’agentique dans le développement logiciel sur mesure. Épisode 2.
Dans notre retour sur expérience, l’architecture testée est composée de trois frontaux et de deux serveurs backend. Les serveurs backend fournissent un service MySQL master/slave, c’est-à-dire qu’il n’y a qu’un serveur actif à la fois et un service de cache Redis qui fonctionne également en master/slave.
Sur les deux backends, le premier est master pour MySQL et slave pour Redis, le second est slave pour MySQL et master pour Redis. Ainsi, les flux réseaux provenant des frontaux sont distribués sur les deux backends.
Le test de charge a été effectué avec JMeter et le nombre de threads augmente de 25 toutes les 10 minutes :
L’utilisation des paliers permet de voir la correspondance avec les métriques côté serveurs. Si tout était idéal, on retrouverait un escalier avec des paliers de 10 minutes sur les graphes des serveurs.
Voici la consommation CPU d’un frontal qu’on peut superposer à la courbe de JMeter, tout du moins au début. On voit que les CPU démarrent par des marches d’escalier, mais au bout du troisième palier, après 30 minutes, la CPU ne suit plus les marches.
C’est typique d’une contention qui apparaît au-delà du troisième palier, donc entre 50 et 75 threads au niveau de JMeter.
On voit que les frontaux reçoivent beaucoup plus de données qu’ils n’en délivrent. Dans la partie verte se trouvent les réponses, c’est-à-dire les pages émises vers les navigateurs et les requêtes faites sur la base de données MySQL et Redis. En bleu, on trouve les requêtes des navigateurs reçues par les frontaux, mais surtout les réponses des backends.
Le serveur MySQL reçoit plus de trafic qu’il n’en délivre ! C’est probablement la réplication Redis qui est la source de ce trafic entrant.
Dans ce trafic émis, il y a la réplication Redis pour une part mais aussi les informations qui permettent à l’application de créer les pages.
Et surtout on note l‘écrêtage du débit au troisième palier avec un flux de 450 Mbps !
Pourquoi atteint on une limite à 450 Mbps alors qu’en théorie on devrait passer du 1000 Mbps ?
Parce qu’en pratique, il y a 4 machines qui conversent avec ce serveur, et elles font énormément de requêtes. Donc on se trouve loin des conditions optimales de débit.
On voit dans le graphes des frontaux que le trafic émis est de l’ordre de 30 Mbps. Donc le site a un débit de moins de 100 Mbps. Alors que le trafic émis par Redis dépasse les 375 Mbps. Il faut trois fois plus d’informations pour construire une page que ce qu’elle ne contient !
On constate pour cette application une surutilisation de Redis. Rien d’étonnant, puisque le Redis stocke les données prêtes à être exploitées par l’application. Les résultats sont pré machés dans Redis et renvoyés directement depuis la mémoire, ce qui accroît les performances. En un peu plus d’une dizaine d’années, le codage des applications passe de l’exécution de requêtes SQL à la lecture des données dans Redis.
En pratique, on utilise Redis comme de la RAM, c’est-à-dire de la mémoire locale. Sauf que quand on a plusieurs frontaux, cette mémoire est partagée. Le bon côté c’est que ça évite de charger des données en cache pour chaque frontal. Le mauvais côté, c’est qu’on accède à cette mémoire à travers le réseau, qui n’a pas du tout les mêmes performances que la RAM.
A noter qu’au bout du troisième palier on sature le réseau, il était donc inutile de faire 8 paliers pendant 1h30 lors de ce test de charge !
Ce type de contention réseau au niveau des backends est assez courante sur les grosses infrastructures qui multiplient les frontaux et les VM ou services.
Les perspectives d’amélioration passent par une modification d’architecture, comme utiliser le Redis avec une réplication master/master ou des lectures sur le slave pour alléger le master. Mais surtout, l’application n’est certainement pas optimisée puisqu’elle nécessite pour pour produire ses pages, la lecture de 3 fois plus de données. Il y a donc très certainement un gâchis de lecture de tableaux dont on ne conserve que quelques informations. La démarche de préservation des ressources prend toute son importance sur les sites à forte audience
Un test de charge consiste à simuler une montée progressive du nombre d’utilisateurs afin d’observer le comportement réel d’une application sous contrainte. Il permet d’identifier des limites invisibles en environnement nominal, notamment les contentions CPU, mémoire ou réseau, impossibles à détecter sans mise sous pression contrôlée..
Une contention réseau backend survient lorsque les échanges entre services internes (frontaux, bases de données, cache) saturent la capacité réseau disponible. Le problème ne vient pas du trafic utilisateur, mais des communications internes nécessaires à la construction des pages.
Parce que dans les architectures modernes, la donnée circule beaucoup plus que le calcul. Dans le cas décrit, Redis est massivement sollicité pour fournir des données pré-calculées, ce qui génère un trafic réseau très élevé avant même que les CPU ne soient saturés.
Redis devient un goulet d’étranglement lorsqu’il est utilisé comme une mémoire partagée entre plusieurs frontaux. Chaque accès Redis transite par le réseau, contrairement à une lecture en RAM locale. Lorsque l’application effectue un grand nombre de lectures Redis pour construire ses pages, le volume d’échanges internes augmente fortement et peut saturer le réseau backend avant même que les CPU ou la base de données ne soient sollicités.
Parce que Redis stocke des données intermédiaires prêtes à être exploitées par l’application, souvent plus volumineuses que le contenu final affiché. Dans le cas présenté, l’application lit jusqu’à trois fois plus de données que nécessaire pour produire une page. Ce surcroît de lectures génère un trafic interne massif, sans bénéfice direct pour l’utilisateur final.
Il met en évidence une inadéquation entre l’architecture technique et les usages applicatifs réels. Une infrastructure peut être dimensionnée correctement, mais rester inefficace si l’application consomme inutilement des ressources. Ce type de test de charge révèle que la performance ne dépend pas uniquement de l’infrastructure, mais surtout de la sobriété des échanges et de l’optimisation applicative.
88 % des transformations échouent sur l’adoption (Bain, 2024). Voici comment toHero utilise le design thinking pour remplacer le MVP par le Minimum
66 % des projets IT échouent. Pas à cause du code. À cause d’interfaces que personne n’a testées avant de les construire. Découvrez comment le
Agentic RAG, orchestration des agents IA, conformité réglementaire et AI Act : comment industrialiser l’agentique dans le développement logiciel sur mesure. Épisode 2.
