Dans le premier épisode, Design Driven Development et prototypage : pourquoi vos projets livrent des interfaces que personne n’utilise, nous avons démontré pourquoi le design doit impérativement précéder le code. Puis, dans le deuxième article de la série, nous avons expliqué pourquoi chez toHero, nous visons systématiquement le Minimum Lovable Product : un produit que les utilisateurs adoptent et choisissent d’utiliser durablement.
Mais il reste pourtant une question laissée en suspens. Une fois le produit livré, comment savoir s’il est vraiment aimé et adopté par les utilisateurs ?
Mais avant d’aller plus loin, il est nécessaire de partager un constat.
Avec l’essor de l’UX/UI design, toute l’industrie du logiciel se dit désormais « centrée utilisateur » (ou plutôt “user centrics” pour les intégrateurs et les agences les plus dans le vent).
Les ESN mettent cet argument en avant en avant-vente, les clients l’inscrivent dans leurs cahiers des charges et les agences l’affichent fièrement en page d’accueil. Pourtant, une fois le produit livré, très peu vérifient que leur promesse s’est bien réalisée.
Les données confirment ce décalage frappant entre argument commercial et réalité terrain.
« 90 % des dirigeants ne parviennent pas à mesurer facilement leurs logiciels au regard des résultats business. Seuls 12 % mesurent encore le succès d’un logiciel un an après son déploiement, et 5 % après trois ans.»
Autrement dit, l’adoption d’un logiciel, qui justifie pourtant l’investissement, n’est presque jamais suivie au-delà des premières semaines après la mise en production.
De notre côté, chez toHero, nous préférons le dire franchement : nous aussi, nous avons longtemps considéré la mise en production comme l’aboutissement d’un projet. Le planning tenu, le budget respecté et la recette validée suffisaient à déclarer la réussite d’un projet. Ce qui pouvait se passer trois mois plus tard dans les équipes de nos clients restait, la plupart du temps, hors de notre champ de vision.
Nommer ce constat a été pour nous la première étape pour le résoudre.
Dans la majeure partie des projets, la mise en production marque la fin du chantier. Elle déclenche la facture finale, la levée des réserves et le passage en maintenance. Pourtant, elle devrait surtout ouvrir une autre phase, la plus révélatrice : celle où l’on découvre si les utilisateurs s’approprient réellement l’outil sur le long terme.
Côté prestataire, l’équipe projet est généralement réaffectée à la mission suivante après la mise en production (MEP.) Et pour ce qui est du client, le produit bascule dans le run, piloté par des indicateurs de disponibilité et de tickets d’incidents.
Quant à l’adoption, elle est souvent confiée à la conduite du changement, qui mesure surtout si les formations au nouveau logiciel ont bien été suivies. Entre les deux, personne n’est explicitement chargé de vérifier si le produit est aimé.
Cet angle mort a un coût bien réel. WalkMe a comparé la perception des dirigeants à la réalité des usages : là où ils pensaient que leur entreprise utilisait en moyenne 37 applications, les données en recensaient 625. Quand on ignore ce que les équipes utilisent vraiment, on ignore également ceux qu’elles délaissent.
Dans le secteur de l’édition de logiciels, le suivi de l’usage est une discipline à part entière, portée par des product managers et des outils d’analytics. Dans le développement sur mesure et dans les équipes projet, rien. On spécifie des fonctionnalités, des délais et des SLA. Selon AppLearn, seuls 45 % des dirigeants disposent d’indicateurs digitaux pour l’ensemble de leurs applications.
Un produit qui fonctionne et un produit qu’on aime relèvent de deux familles d’indicateurs distincts. La première vérifie l’absence de problème, tandis que la seconde mesure la présence d’attachement utilisateur. Un projet sur-mesure a besoin de ces deux familles d’indicateurs pour savoir où il en est vraiment.
Après une mise en production, le premier réflexe consiste à compter ce qui bloque. Encore faut-il distinguer ce qui relève du code de ce qui relève du parcours utilisateur.
Ces quatre indicateurs disent clairement si le produit « fonctionne ». En revanche, ils ne disent rien de l’envie des utilisateurs d’y revenir.
Ce dernier indicateur mérite une attention toute particulière, parce que c’est souvent là que se cache un budget gaspillé.
« 80 % des fonctionnalités d’un logiciel moyen sont rarement ou jamais utilisées.»
ÉPISODE 3 · MESURER UN LOVABLE PRODUCT
Deux familles de métriques
Ça marche ou c'est lovable ? Un projet sur mesure a besoin des deux.
Elles vérifient l'absence de problème.
Elles mesurent la présence d'attachement.
Illustration N°1 - Métriques de non-friction VS métrique d'attachement, cadre Lovable toHero
Parmi toutes ces métriques, le Net Promoter Score occupe une place à part. Il a en effet le don de traduire l’attachement en un seul chiffre facilement compréhensible par un comité de direction. Son principe est simple : on demande aux utilisateurs, sur une échelle de 0 à 10, s’ils recommanderaient l’outil à l’un de leurs collègues de travail.
Le calcul du NPS repose ensuite sur trois groupes. Les promoteurs représentent les utilisateurs qui donnent une note de 9 ou 10 sur 10. Les passifs donnent une note de 7 ou 8 et les détracteurs sont ceux qui accordent une note de 0 à 6 à la solution livrée. Le score NPS correspond au pourcentage de promoteurs moins le pourcentage de détracteurs. Il varie donc de -100 à +100.
Dans cet exercice, tout se joue cependant dans le moment où l’on interroge les utilisateurs. Le jour de la livraison, le NPS mesurera surtout l’effet de nouveauté et la satisfaction client vis-à-vis du projet. Après 30 jours, d’usage réel le Net Promoter Score reflétera bien plus l’expérience quotidienne des utilisateurs avec ses leurs irritants comme ses satisfactions. C’est pourquoi nous recommandons toujours d’interroger les utilisateurs à J+30, puis à J+90, pour observer la trajectoire du NPS plutôt qu’une simple photographie figée et isolée.
L’effet waouh n’arrive jamais par chance le jour du lancement. Il se prépare au cadrage, en identifiant les quick wins d’attachement décrits dans l’épisode 2, puis se valide sur prototype avant l’écriture du code. Pourtant, même réussi, il ne garantit rien s’il n’est pas suivi dans la durée.
Gartner l’a observé à grande échelle sur un outil très attendu.
« 90 % des répondants déclarent qu’ils se battraient pour conserver leur accès à Microsoft 365 Copilot. Pourtant, 72 % peinent à l’intégrer dans leur routine quotidienne et 57 % constatent un engagement qui décroît rapidement. »
L’enthousiasme initial et l’adoption durable sont deux choses différentes. Seule une mesure étalée sur plusieurs semaines permet réellement de les départager.
Trois signaux indiquent que l’effet waouh a bien opéré. D’abord, un onboarding fluide, terminé sans assistance. Puis, un premier usage autonome, réalisé sans formation préalable. Enfin, un retour spontané dans les jours qui suivent, sans relance ni obligation.
À l’inverse, trois signaux doivent immédiatement alerter. Les tickets de type « Je n’arrive pas à… » qui se multiplient, la non-utilisation des fonctionnalités secondaires, et surtout, les contournements : fichiers Excel parallèles, applications personnelles, anciens outils conservés « au cas où ».
Ce dernier signal prend de l’ampleur. Selon Gartner, 41 % des salariés ont acquis, modifié ou créé une technologie hors de la visibilité de la DSI en 2022, et cette part devrait atteindre 75 % d’ici 2027. En France, 28 % des salariés reconnaissent utiliser des appareils ou des applications personnels pour accomplir leurs tâches, d’après une étude Sapio Research pour TeamViewer, publiée en 2025. Chaque contournement est un utilisateur qui a voté contre l’outil officiel, sans le dire.
ÉPISODE 3 · L'EFFET WAOUH APRÈS LA MISE EN PRODUCTION
Les signaux qui ne trompent pas
À surveiller dans les semaines qui suivent la mise en production.
Illustration n°2 - Signaux positifs et négatifs de l'effet whaou après mise en production
Notre proposition est simple à formuler mais exigeante à appliquer : faire entrer les métriques Lovable dans la définition du succès, au même titre que le respect du planning et du budget. Un projet réussi devient alors un projet livré dans les délais et adopté durablement par les utilisateurs.
Dès la réunion de cadrage du projet, nous définissons avec le client 3 à 5 signaux qui prouveront, une fois le produit en production, qu’il est adopté et aimé. Ce nombre reste volontairement limité, parce qu’au-delà, la mesure se dilue et plus personne ne la pilote vraiment.
À titre d’exemple, pour un portail métier B2B, ces signaux pourraient être constitués du taux de rétention hebdomadaire sans relance, du time-to-value de la première commande, du taux d’abandon de l’onboarding, du Net Promoter Score à 30 jours ou encore du recul des fichiers Excel parallèles.
Les seuils se fixent avec le client, en fonction de son contexte, de ses besoins et de ses équipes.
Une fois définis, ces signaux guident chaque décision. Une fonctionnalité qui ne sert aucun d’entre eux descend dans le backlog, tandis qu’un écran qui conditionne le time-to-value mérite davantage d’investissement en design. Le budget suit ainsi ce qui crée l’adoption, pas uniquement ce qui coche le cahier des charges projet.
C’est l’approche que nous déployons sur nos projets de Solution métier à la demande comme sur nos projets d’Application Mobile où l’usage réel s’observe dès le premier jour de production.
ÉPISODE 3 · LE CADRE toHero
Des métriques Lovable dès le cadrage
3 à 5 signaux définis avec le client, suivis après la mise en production.
Les signaux Lovable entrent dans les critères de succès du projet, au même titre que le planning et le budget.
Les signaux priorisent le backlog et orientent l'investissement en design.
Taux de rétention, time-to-value et Net Promoter Score sont mesurés dans la durée.
Illustration n°3 - Cadre toHero : 3 à 5 signaux Lovable définis dès le cadrage
Viser le Minimum Lovable Product sans mesurer l’adoption revient à faire une promesse impossible à vérifier. Le design thinking, le prototypage et le handoff Figma-first posent les conditions de l’attachement. Le taux de rétention et le Net Promoter Score, eux, prouvent que cet attachement existe réellement.
L’industrie sait mesurer la disponibilité d’un serveur à la seconde près, mais elle mesure rarement si les utilisateurs ont envie d’ouvrir le logiciel le lundi matin. Faire entrer les métriques d’attachement dans les contrats, les cadrages et les comités de pilotage constitue la prochaine étape. Nous comptons y prendre notre part, et nous poursuivrons cette réflexion dans une série entièrement dédiée au Lovable Product.
D’ici là, nous aimerions confronter ce cadre à vos projets. Quels signaux suivez-vous aujourd’hui après une mise en production ?
Vous travaillez sur un projet et vous souhaitez définir vos métriques Lovable dès le cadrage ?
Parlons-en.
On demande aux utilisateurs, sur une échelle de 0 à 10, s’ils recommanderaient l’outil à l’un de leurs collègues. Le score NPS correspond au pourcentage de promoteurs (notes 9 et 10) moins le pourcentage de détracteurs (notes 0 à 6). Ainsi, il varie de -100 à +100.
Le jour de la livraison, le NPS mesure surtout l’effet de nouveauté de la solution déployée. Après 30 jours d’usage réel, il reflète l’expérience quotidienne des utilisateurs et devient un indicateur d’attachement fiable, à suivre ensuite à J+90.
On combine des métriques de friction (tickets support d’adoption, taux d’erreur, temps de complétion) et des métriques d’attachement (taux de rétention, time-to-value, NPS à 30 jours, feature adoption rate), définies dès le cadrage.
Le time-to-value mesure le délai entre le premier accès d’un utilisateur et sa première action clé réussie. Plus il est court, plus l’utilisateur perçoit rapidement la valeur du produit.
Chez toHero, nous recommandons 3 à 5 signaux définis avec le client. Ce nombre limité permet de les piloter réellement et d’en faire la base des arbitrage design et budget.
Les signaux positifs comprennent un onboarding fluide, un premier usage autonome et un retour spontané. Les signaux négatifs sont des tickets « je n’arrive pas à… » qui se multiplient, les contournements et la non-utilisation des fonctionnalités secondaires.
toHero, ESN basée à Montpellier, applique la méthode Minimum Lovable Product à ses projets sur mesure. Les équipes UX/UI et développement conçoivent et testent les parcours sur prototype, avant d’écrire le code. Dès le cadrage elle définissent avec avec le client 3 à 5 signaux d’adoption, comme le Net Promoter Score à 30 jours.
WalkMe, The State of Digital Adoption 2025, communiqué du 25 février 2025
Gartner, Copilot for Microsoft 365 : Assessing the Impact and Value So Far, 8 août 2024
Gartner, Top Eight Cybersecurity Predictions for 2023-2024, communiqué du 28 mars 2023
TeamViewer, L’impact des frictions numériques, enquête Sapio Research d’août-septembre 2025, chiffre France repris par Presse Agence, 27 juin 2026
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après
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.
Épisode 2 de la série Design Driven Development
Dans le premier épisode, Design Driven Development et prototypage : pourquoi vos projets livres des interfaces que personne n’utilise, nous avons posé le diagnostic. Le design arrive trop tard dans les cycles de développement logiciel. Le prototypage placé avant le premier sprint change la donne. Et les 5 principes fondateurs du DDD (Design Driven Development) chez toHero transforment la façon dont les équipes prennent leurs décisions.
Même avec le bon processus, il reste possible de livrer parfaitement quelque chose que personne n’aime vraiment utiliser. C’est le problème que cet épisode évoque directement. Et c’est exactement ce que le design thinking résout à la racine.
Ahhhh les problèmes. Ils sont partout, et sans qu’on s’en rende compte, d’autres apparaissent sans cesse. C’est un peu le quotidien de nos métiers et aussi la raison pour laquelle nous avons choisi de le faire.
Le MVP (Minimum Viable Product) a rendu un réel service à l’industrie du logiciel. Il a permis de tester et livrer plus tôt, tout en évitant des mois de développement en chambre noire. Une réponse légitime au risque budgétaire.
Pourtant le MVP constitue une réponse inadéquate à une problématique réelle.
La question qu’il pose est avant tout comptable : quelle est la version minimale livrable du produit ?
Autrement dit, qu’est-ce qui est acceptable pour ce projet d’un point de vue financier ? Le MVP protège le budget et occulte alors le plus important : le facteur d’adoption.
C’est précisément là que le design thinking apporte une réponse différente. Là où le MVP part des contraintes techniques et budgétaires, le design thinking part des usages réels, des besoins exprimés et des frustrations non formulées des utilisateurs. Ce renversement de perspective change tout : on ne construit plus ce qui est faisable en premier, mais ce qui sera utilisé.
Les chiffres sont sans appel :
« 88 % des transformations d’entreprise n’atteignent pas leurs ambitions initiales. Seuls 12 % livrent réellement ce qu’elles ont promis. »
En France, 57 % des entreprises souhaitent une simplification de leurs outils digitaux. Et 32 % estiment avoir besoin d’accompagnement pour faciliter l’appropriation des outils par leurs collaborateurs, selon le baromètre ACSEL 2024. Les outils sont donc là. L’investissement est réel mais l’adoption, elle, ne suit pas.
Un produit fonctionnel que personne n’utilise spontanément est un problème de taille pour les organisations. Parce qu’il constitue un budget immobilisé sans valeur ajoutée. Dans le cadrage d’un MVP agile, la question de l’attachement utilisateur arrive rarement en premier. Pourtant c’est ce petit détail en apparence, qui fait toute la différence.
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.
« Lovable » pourrait faire l’objet d’un superbe slogan de communication. Mais ça serait passer à côté de l’essentiel. Lovable signifie « aimable » en traduction littérale de l’anglais. C’est le cœur de notre méthodologie et toute l’ambition de notre approche design thinking appliquée au développement logiciel.
En proposant un MLP (Minimum Lovable Product), nous construirons des produits fonctionnels mais surtout aimés et adoptés par leurs utilisateurs. De notre côté, en interne, le MLP à totalement changé notre façon de cadrer, d’allouer un budget ou encore de prioriser un backlog. Et ce dès les premières phases du cycle de développement projet.
Notre intention avec ce changement de paradigme est clair : placer en priorité deux objectifs qui structurent toute notre approche produit.
Maximiser l’adoption. L’adoption volontaire est un élément fondamental pour créer de la valeur perçue mesurable dans les premières semaines de déploiement. Ici l’utilisation est naturelle. Elle se fait par les utilisateurs sans contrainte de hiérarchie ou de formation obligatoire.
Maximiser le repeat. Un produit aimable / lovable est un produit conçu pour rendre un service réel, efficace, fluide et plaisant aux utilisateurs. C’est un produit qu’ils viennent utiliser spontanément parce qu’il leur facilite le travail ou le quotidien. C’est là que se trouve toute la différence entre un outil toléré parce que son utilisation est obligatoire, d’un produit recommandé aux collègues parce qu’il fait vraiment gagner du temps.
À ce propos les données sont sans appel :
Trois mois. C’est le temps dont un produit dispose pour créer l’attachement et installer le repeat naturellement chez les utilisateurs.
«57 % des acheteurs de logiciel B2B attendent un ROI positif dans les 3 mois suivant leur achat.»
Le cadrage est donc le moment où tout se joue lors de la création produit. C’est précisément parce que c’est à cet instant précis que l’on décide quoi construire, dans quel ordre et surtout avec quel budget.
A cette étape, on identifie les quick wins d’attachement. C’est-à-dire, tous les éléments fondateurs qui créent une adhérence immédiate dans le cycle de développement.
Ce recul et ce focus coûtent souvent peu à concevoir. Mais leur impact sur l’adoption est impressionnant.
Ce qui distingue les quick wins des fonctionnalités classiques, c’est leur effet de levier sur le comportement utilisateurs dès les premières semaines après lancement. Un tableau de bord illisible génère de la frustration immédiate.
À contrario, une navigation fluide installe une confiance en quelques secondes. L’ensemble de ces facteurs ne sont pas des détails esthétiques mais bien des décisions architecturales qui conditionnent l’adoption avant même que le produit soit complet.
Dans notre pratique du design thinking, nous identifions tous les quick wins en amont du premier sprint, lors de session de recherche utilisateur et d’idéation. C’est ce souci d’anticipation qui fait la différence entre un déploiement réussi et un lancement que l’on doit accompagner de force.
Dans un cadrage classique, le budget est alloué en fonction de la valeur fonctionnelle d’une feature. Est-ce qu’elle couvre vraiment un besoin métier ? Dans un cadrage lovable, une dimension supplémentaire s’ajoutent aux interrogations. Est-ce que cette feature génère de l’attachement, du plaisir d’usage et de l’envie de revenir ?
La valeur perçue par l’utilisateur devient ainsi un critère de priorisation au même titre que la valeur fonctionnelle. De quoi provoquer un glissement qui change l’ordre des décisions dans le backlog et l’allocation du budget dès le cadrage.
Les données confirment d’ailleurs que ce choix est hautement stratégique plus qu’esthétique.
Adobe confirme aussi cette dynamique : 50 % des entreprises dites « design-driven » rapportent une fidélité client plus élevée, signe que le design est un levier structurant de la rétention utilisateurs sur le long terme.
Pour une ETI qui déploie un outil métier sur des dizaines ou des centaines de collaborateurs, l’adoption va plus loin. Elle représente le premier KPI pour les entreprises.
Chez toHero, c’est justement ce levier que nous activons dès la cadrage, bien avant le premier sprint. Notamment sur nos projets de solution métier à la demande, où l’adoption par les équipes métier est le premier indicateur de succès.
« +32 % de croissance de revenus pour les entreprises driven-design vs leurs pairs. »
Un minimum lovable product sans méthode reste une simple intention. Et c’est déjà très bien d’en avoir l’idée. Mais le Design Driven Development est littéralement l’infrastructure qui le rend opérationnel.
Sans prototypage et recherche utilisateur en amont, personne ne sait réellement ce qui crée de l‘attachement pour la cible. On suppose. On projette. On livre avec bonne fois mais ça ne résonne pas in fine.
L’effet whaou se conçoit ainsi au premier déploiement à partir des données utilisateurs réelles.
Chez toHero, c’est ce constat qui structure notre approche. On place les décisions là où elles ont de l’impact : avant que le maquettage deviennent du code, et avant que le prototype devienne une contrainte budgétaire. C’est valable sur tous nos projets, y compris en application mobile, où chaque écran doit convaincre au premier lancement.
Le processus DDD (Design Driven Development) n’est pas une méthode qui s’improvise. Chaque étape doit préparer la suivante dans un savant mélange de structure. La recherche utilisateur alimente l’idéation, l’idéation pose les fondations du prototype, le prototype valide le handoff. Ce dernier conditionne la qualité de chaque itération. Grâce à cet enchaînement rigoureux, l’intention lovable est ainsi transformée en produit adopté.
La recherche utilisateur est la première étape de notre pratique du design thinking. Elle cartographie les points de friction qui freinent l’adoption, les moments de satisfaction qui créent l’attachement et les besoins non formulés que les utilisateurs n’arrivent pas à exprimer mais qui conditionnent leur rapport au produit. Sans cette étape, le backlog est construit sur des hypothèses d’équipe, et non sur des réalités terrain.
« Les équipes qui ont adopté une culture de recherche utilisateur partagée sont 2 fois plus susceptibles de voir la recherche influencer leurs décisions stratégiques, et 1,8 fois plus susceptible de confirmer qu’elle impacte directement les décisions produit. »
Les phases d’idéation et de maquettage permettent de structurer le design system avant toute ligne de code. Le design system représente ainsi le référentiel partagé entre designers et développeurs : composant, tokens, typographies, espacements. Tout ce qui garantit qu’un produit reste cohérent, quelle que soit la fonctionnalité ajoutée.
Cette cohérence perçue installe la confiance : l’utilisateur sait où il est, ce qu’il peut faire et comment avancer. Elle prépare le repeat et accélère le handoff. Le tout, en évitant les interprétations tronquées entre ce que le designer a conçu et ce que le développeur implémente.
Concernant le prototypage, il valide deux interrogations distinctes dans le cycle de développement. D’abord que les fonctionnalités marchent puis qu’elles créent réellement de l’attachement. Ainsi, la première question s’adresse au bon fonctionnement des features, quand la seconde s’adresse à l’intention de revenir (repeat). C’est pour répondre parfaitement à cette validation de l’adoption que toHero, ne démarre jamais un sprint sans avoir répondus à ces deux prérequis.
« Corriger une erreur de conception en phase de prototypage coûte 10 fois moins cher qu’en phase de développement, et 100 fois moins qu’après livraison. »
« Les organisations qui investissent dans le prototypage UX en phase de conception réduisent leurs cycles de développement de 33 à 50 %. »
Le handoff est l’une des phases les plus dangereuses d’un projet. En effet, c’est le moment précis durant lequel, les intentions de maquettage peuvent se perdent, que les interactions disparaissent parfois et que le produit livré ressemble vaguement ce qui a été validé sur prototype.
IBM Systems Science Institut confirme ce constat : corriger une erreur après livraison coûte 100 fois plus cher qu’en phase de conception. Chaque ambiguïté non résolue avant le premier sprint est une dette qui se paie cash au développement.
C’est pour toutes ces raisons, qu’à toHero, le handoff Figma-First est une règle non négociable : spécifications visuelles complètes, assets et tokens sont toujours transmis avant le passage au développement. Une méthode rigoureuse, qui nous permet de ne rien perdre entre la valeur perçue validée et ce que l’utilisateur reçoit en boût de chaîne.
Notre approche minimum lovable product mesure l’attachement utilisateur à chaque itération. Et pour se faire, deux questions structurent chacun de nos sprints. Est-ce que les utilisateurs reviennent spontanément utiliser le produit livré ? Est-ce que la fonctionnalité créé est utilisée sans formation ?
La complétion technique est comme un plancher. Un point de départ.
Là où l’attachement ou l’adoption est le plafond, l’objectif à atteindre.
Un MVP promet un produit fonctionnel livré dans les délais. Il est comptablement compatible avec les attentes fixées par la direction. C’est une promesse utile, mais restreinte.
Le MLP (Minimum Lovable Product) quant à lui, projète exactement la même chose en y ajoutant ce quelque chose en plus qui fait toute la différence. La garantie que le produit livré sera réellement utilisé et adopté par les utilisateurs. Un objectif important qui satisfait à la fois la direction financière et les équipes métiers. Ces mêmes équipes métier qui ont la mission de faire avancer l’activité de l’organisation avec des outils qu’ils maîtrisent et qu’ils apprécient.
Grâce à notre approche Lovable et à la mise en pratique du Design Driven Development, cette promesse est ainsi possible. C’est en changeant l’ordre des décisions dans le cycle de développement, la hiérarchie des priorités dans le backlog et la façon dont on mesure le succès d’un projet, qui fait ainsi toute la différence.
Chez toHero, le DDD et notre méthodologie MLP constituent la colonne vertébrale de notre offre UX/UI et Direction artistique pour permettre aux DSI et CTO qui déploient pour des centaines d’utilisateurs, des solutions numériques appréciées et adoptées.
C’est également l’approche que nous appliquons pour l’ensemble de nos projets d’intégration ERP et PIM où le concept d’adoption par les équipes terrain est le premier KPI mesuré après le go-live. Parce qu’un produit que vos utilisateurs aime utiliser ne devrait jamais être un luxe mais bien la condition pour qu’un investissement digital génère un retour mesurable.
Dans le prochain épisode de cette série d’articles dédiés au Design Driven Development, nous répondrons à cette question que tout le monde esquive : comment sait-on réellement qu’un produit est vraiment lovable ? NPS, taux de retour spontané, usage sans formation sont les indicateurs que nous mesurons après chaque déploiement et notre méthode pour décider en données plutôt qu’en intuitions.
Le design thinking est une approche de conception centrée sur les usages réels des utilisateurs. Appliqué au développement logiciel, il inverse l’ordre classique des décisions. Ainsi, on part des besoins, des frustrations et des comportements terrain avant de définir les fonctionnalités à développer. Résultat : le produit conçu et construit est utilisé par la cible d’utilisateurs.
Le Minimum Lovable Product est la version minimale d’un produit conçu pour maximiser l’adoption et le repeat. Cette technique se base sur ce qui crée réellement l’attachement et l’adoption dès la première utilisation. Contrairement au MVP (minimum viable product), il priorise la valeur perçue plutôt que la valeur fonctionnelle.
Le MVP vise la version minimale livrable et fonctionnelle d’un produit dans le cycle de développement. De son côté le MLP vise la version minimale que les utilisateurs aimeront et voudront adopter dans leurs quotidien. L’enveloppe budgétaire peut être similaire entre les deux approches mais la priorisation du backlog est fondamentalement différente dès le cadrage.
Sans prototypage et recherche utilisateur réalisés en amont du cycle développement, un MLP reste une simple intention. Le DDD constitue l’infrastructureméthodologique qui garantit que les décisions d’adoption précèdent bien les décisions de développement, du maquettage jusqu’au handoff.
Il réalloue le budget différemment. Les quick wins d’attachement sont souvent des investissements modestes à fort impact sur l’attachement. McKinsey, le mesure : + 32 % de croissance de revenus sur cinq ans sont possible pour les entreprises design-driven vis à vis de leurs pairs.
Oui, et c’est d’ailleurs là que l’enjeu adoption est le plus fort. Les utilisateurs ont des habitudes établies et le droit de contourner une solution ou un outil. Le DDD permet d’identifier les quick winsd’attachement qui réduisent ce risque dès le cadrage, du maquettage jusqu’à l’itération finale.
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après sa mise en production.
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.
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.
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après sa mise en production.
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.
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après
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.
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après sa mise en production.
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.
Votre site est installé sur une distribution Debian Buster avec Nginx/Apache/PHP/MySQL.
Votre site utilise Nginx pour la terminaison SSL, l’objectif consiste à intercaler Varnish entre Apache et Nginx !
L’opération d’installation de Varnish est assez simple. Il faut néanmoins maîtriser la ligne de commande sous Linux et prendre soin de vérifier le bon fonctionnement du cache après installation.
L’objectif, si Nginx redirige les requêtes des ports 80 et 443 vers le port d’écoute Apache (8080 souvent dans ce cas), sera de rediriger les ports 80 et 443 vers le port d’écoute de Varnish, qui par défaut est le 6081. Varnish redirigera à son tour les requêtes sur le port 8080 d’Apache. Le «backend» de Varnish sera le serveur Apache, en localhost sur le port 8080.
Pour installer Varnish sur Debian, il suffit de lancer la commande :
Jusque là, comme Varnish s’installe par défaut sur le port 6081, il n’y a aucun impact sur le Magento !
On prépare la configuration de Varnish qui se trouve dans /etc/varnish/default.vcl.
A noter que cette configuration est fournie par Magento 2 lui même.
Sauvegardez la version d’origine avant de la modifier avec la version à télécharger ici !
Dans ce fichier, il faut vérifier le paragraphe qui définit l’endroit où seront redirigées les requêtes qui arrivent depuis Varnish.
Afin que Nginx redirige les requêtes sur Varnish, il suffit de les envoyer sur le port 6081 au lieu du port 8080.
Dans le fichier de configuration de Nginx, par exemple : /etc/nginx/sites-enabled/reverse-proxy.conf on passe proxy-pass http://localhost:8080 à proxy-pass http://localhost:6081
Le redémarrage de Nginx permet la prise en compte du changement de port :
Une fois Varnish installé, on peut vérifier l‘amélioration des performances.
La première étape consiste à purger le cache de Varnish. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :
Le «.» indique 0 et 1 caractère n’importe lequel. Donc toutes les URLs vont matcher cette expression régulière. Toutes les URLs seront donc bannies.
On peut vérifier les temps de réponse avec cUrl. On prépare un fichier pour le formatage des temps de réponse comme suit :
On met Magento en mode debug pour voir les entêtes Varnish. On lance une première requête après le vidage du cache :
On remarque que l’en-tête X-Magento-Cache-Debug vaut MISS.
La page est servie depuis Apache car elle n’était pas disponible au niveau de Varnish. Mais comme cette page a un Max Age d’une journée, elle a vocation a être cachée. Une deuxième requête identique doit montrer que la page est servie du cache de Varnish.
On remarque que l’en-tête X-Magento-Cache-Debug vaut HIT et Varnish a mis la page en cache depuis 70 secondes (entête Age). Ce qui correspond bien à notre première requête !
On vient de diviser le temps de réponse par un facteur 10 !
Si on demande la même page directement depuis Apache, on obtiendrait :
Soit un temps de réponse voisin de celui de Varnish quand la page n’est pas cachée. Ce facteur 10 prouve l’intérêt de Varnish, qui va pouvoir servir tous les contenus statiques, images, JS et CSS et pages également, lorsqu’elles n’ont pas de cookies de session, c’est à dire qu’elle ne dépendent pas de l’utilisateur.
C’est donc un gain pour l’expérience utilisateur autant que pour supporter la charge lors des fortes audiences comme les soldes !
Un système agentique est un système d’IA capable d’exécuter des actions dans un environnement donné pour atteindre un objectif défini. Contrairement à un modèle IA classique qui répond à une question, un agent IA peut enchaîner des étapes, utiliser plusieurs outils et itérer en continu jusqu’à complétion de la tâche.
Un générateur produit du code à partir d’instructions. 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’à ce que tout fonctionne.
RAG signifie Retrieval-Augmented Generation. En version classique, un RAG enrichit les réponses d’un modèle IA en lui fournissant des documents de référence. En version agentique, le RAG devient proactif : c’est l’agent lui-même qui décide quelles informations 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é.
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, pas un remplaçant. Le rôle humain reste central pour l’architecture, la conception, la supervision et la qualité.
Parce que les agents IA peuvent accélérer des workflows complets. McKinsey estime une réduction de 20 à 60 % des cycles de relecture. BCG observe que 90 % des CEOs anticipent un ROI mesurable des agents IA dès 2026.
Oui. L’AI Act entré en vigueur en août 2024 encadre l’IA au niveau européen. Les obligations relatives aux systèmes à haut risque s’appliqueront dès août 2026, incluant des exigences de transparence, de traçabilité et de supervision humaine.
Collaborateur toHero
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après
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.
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.
Net Promoter Score à 30 jours, taux de rétention, time to value : les métriques pour vérifier qu’un logiciel est vraiment adopté après
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.
