Transformation agentique de l’IA : la stratégie en 4 étapes de Google
Dimanche matin dernier, j’ai eu une petite dispute avec moi-même. Je venais de terminer la cartographie du septième « agent IA » que j’avais construit ce trimestre — une petite solution élégante propulsée par Claude, qui récupère les prix des concurrents, les dépose dans un tableau, puis m’envoie une alerte sur Slack. Ça fonctionne. Ça me fait gagner peut-être quarante minutes par semaine. Et en regardant le schéma, j’ai ressenti un certain malaise.
J’avais construit sept agents. J’avais construit zéro workflow.
Cette distinction peut sembler être du pinaillage sémantique, jusqu’à ce qu’on s’y attarde vraiment. Ensuite, ce n’est plus du pinaillage : c’est la raison même pour laquelle la plupart des projets pilotes d’IA en entreprise s’éteignent discrètement lors de leur deuxième année. C’est précisément ce problème que le nouveau cadre de transformation agentique de l’IA de Google — celui que Clara détaille dans le cours Agentic Strategy sur Google Skills — vise à résoudre.
J’ai passé une bonne partie de trois jours à décortiquer ce cadre, à le confronter à mes propres projets, et à tester sa robustesse hors d’une démo commerciale bien huilée. Certains aspects ont changé la façon dont je structure mon prochain accompagnement client. D’autres me semblent franchement trop complexes pour les créateurs solo. Et une étape en particulier — l’ingénierie de la valeur — est celle que j’aurais aimé qu’on me donne il y a dix-huit mois.
Laissez-moi vous montrer ce que j’entends par là.
La différence entre un agent et un workflow agentique
Voici la phrase qui a tout changé pour moi : un agent IA exécute une tâche. Un système IA agentique exécute un processus.
Lorsque j’ai construit ce scraper de prix concurrents, j’ai créé un agent. Il fait une chose, à un moment donné, puis il s’arrête. Un humain doit encore examiner les données, décider si nos prix doivent évoluer, rédiger la demande de modification, obtenir l’approbation et la mettre en production. L’agent est un outil. Le workflow reste entièrement humain.
Un système agentique, c’est ce qui se produit quand on arrête de confier à l’IA des tâches isolées pour lui déléguer l’ensemble du processus. Il récupère les prix des concurrents. Il évalue si l’écart est significatif. Il vérifie notre politique de marge. Il rédige une proposition de changement de prix. Il la soumet à la personne chargée de l’approuver. Il applique la mise à jour au catalogue produit. Il surveille la conversion pendant les 72 heures suivantes et, selon les résultats, maintient ou annule la modification.
Ce n’est pas un agent plus puissant. C’est une catégorie de système totalement différente.
La perspective de Google — et je pense qu’elle est juste — est que nous sommes à un point de bascule similaire à celui du cloud computing vers 2010 ou du mobile vers 2008. Pas simplement « un nouvel outil utile ». Une réorganisation de la façon dont le travail s’effectue. Les entreprises qui ont compris tôt l’architecture cloud-native ont surpassé celles qui voyaient AWS comme de simples « serveurs loués ». La même fracture commence à apparaître aujourd’hui entre l’IA agentique et l’IA limitée à la tâche.
Et nulle part cette fracture n’est plus visible que dans le retail.
Commerce agentique et la mort silencieuse du clic
Voici un chiffre qui devrait retenir l’attention de tout fondateur d’e-commerce. eMarketer prévoit que le commerce électronique piloté par des plateformes d’IA atteindra environ 20,9 milliards de dollars en 2026 — soit une multiplication par 4 par rapport à 2025. McKinsey estime que le commerce agentique générera 1 000 milliards de dollars de revenus dans le retail américain d’ici 2030. Morgan Stanley pense que près de la moitié des acheteurs en ligne utiliseront des agents d’achat IA à cette échéance, représentant environ un quart de leurs dépenses.
Traduction : une part significative de vos futurs clients ne verra jamais votre page d’accueil. Ils indiqueront à un agent ce dont ils ont besoin. L’agent l’achètera pour eux.
C’est ce que l’on entend par « commerce sans clic », et cela se reflète déjà dans les données de trafic — le trafic des moteurs de recherche vers les destinations de marque a chuté d’environ 25 % à l’approche de 2026, avec une migration nette vers des canaux GenAI comme ChatGPT, Perplexity et Gemini, qui assurent la découverte et, de plus en plus, la transaction. Environ 70 % des consommateurs déclarent être au moins assez à l’aise à l’idée de laisser un agent IA effectuer des achats en leur nom. 45 % utilisent déjà des assistants IA pour trouver des idées de produits. 13 % ont effectivement finalisé un achat via l’un d’eux — et ce chiffre est le signal d’alerte, pas la limite supérieure.
Je reviendrai sur ce que cela implique pour la façon dont vous construisez vos pages produits — il y a une conséquence spécifique, et peu reluisante, pour le SEO que la plupart des équipes n’ont pas encore intégrée. Mais d’abord, le cadre lui-même, car c’est ce cadre qui vous dira si vous construisez quelque chose qui survivra à cette mutation… ou qui disparaîtra avec elle.
Le cadre en quatre étapes de Google, testé sur des projets réels
Le cadre comporte quatre étapes : Découvrir, Concevoir, Construire, Déployer à l’échelle. Cela ressemble étrangement à tous les autres slides de cabinets de conseil que j’ai pu voir. Mais ce n’est pas le cas. C’est la substance de chaque étape qui fait toute la différence, et l’ordre a bien plus d’importance qu’on ne veut bien l’admettre. Je vais vous guider à travers chaque étape telle que Clara l’organise dans le cours, puis je vous dirai où, selon moi, le cadre se plie dans la pratique.
Étape 1 : Découvrir — Le changement de perspective « Et si ? »
L’étape Découvrir est avant tout cognitive. La thèse, c’est que la plupart des entreprises abordent l’IA avec une mentalité « tel quel » — c’est-à-dire qu’elles examinent leurs processus existants et se demandent : « Où peut-on intégrer l’IA pour aller plus vite ? » Cette question a un plafond, et il est bas. On obtient simplement une version accélérée du même processus. Une tâche de quarante minutes devient une tâche de douze minutes. Sympa. Mais pas transformateur.
La mentalité « et si ? » pose une question différente. Elle dit : si nous avions un système infatigable, raisonnablement intelligent, capable d’observer, de décider et d’agir sur l’ensemble de ce processus de bout en bout, à quoi ressemblerait ce processus ? On cesse d’optimiser les étapes pour se demander si ces étapes doivent exister tout court.
J’ai testé cet exercice sur un workflow d’onboarding client que j’étais en train de « IA-ifier » pour un petit SaaS. Avec la pensée « tel quel », je construisais un agent qui rédigeait des emails de bienvenue. Avec la pensée « et si ? », je me suis demandé : pourquoi y a-t-il un email de bienvenue ? Il existait pour guider manuellement un nouvel utilisateur lors de la configuration. Si un agent peut détecter un nouveau compte, observer la première session de l’utilisateur et proposer de l’aide de façon proactive dans le produit dès qu’il rencontre une difficulté — alors il n’y a plus d’email de bienvenue. Plus de guide de configuration. Plus de ticket au centre d’aide du type « comment démarrer ». Toute la structure de l’onboarding change.
Voilà l’écart entre « tel quel » et « et si ? ». Et l’inconfort de cet écart est le véritable livrable de la première étape. Vous êtes censé en sortir un peu désorienté. Si vous en sortez avec une liste bien rangée de « points où mettre de l’IA », c’est que vous avez raté l’exercice.
Étape 2 : Concevoir — Ingénierie de la valeur et parcours utilisateur critiques
C’est, selon moi, la véritable pépite du cadre, et celle qui est la plus sous-estimée dans les discussions sur l’IA agentique. L’étape deux remplit deux fonctions : elle vous oblige à quantifier la valeur business de chaque projet agentique potentiel avant de le construire, et elle vous fait cartographier les Parcours Utilisateur Critiques — les CUJ — que le système agentique devra gérer.
L’ingénierie de la valeur, en termes simples, c’est la discipline qui consiste à refuser de construire le prochain projet IA tant que vous ne pouvez pas répondre à trois questions : qu’est-ce que cela change concrètement pour l’entreprise en euros ou en heures, qui est la personne responsable de ce résultat aujourd’hui, et que devient le poste de cette personne lorsque l’agent fait le travail correctement. Si vous ne pouvez pas répondre précisément aux trois, le projet retourne dans la file d’attente. Il ne sera pas priorisé simplement parce que quelqu’un, lors d’un séminaire de direction, a prononcé le mot « IA » avec conviction.
Soyons honnêtes — c’est à cette étape que j’ai moi-même été le pire contrevenant. J’adore construire. Je rationalise la valeur après coup. Le cadre part du principe, à juste titre, que la plupart d’entre nous feront pareil, et il impose cette discipline avant même qu’une seule ligne de code ne soit écrite.
La cartographie des Parcours Utilisateur Critiques est le pendant opérationnel. Un CUJ n’est pas une liste de fonctionnalités. C’est le chemin précis qu’un humain réel (ou un agent agissant pour un humain) emprunte pour accomplir quelque chose d’important. On cartographie le parcours, on note chaque point de décision, chaque dépendance de données, chaque endroit où le processus actuel se casse ou passe la main à un autre système. Ensuite, on se demande quelles étapes un agent pourrait prendre en charge de bout en bout, et lesquelles nécessitent encore un humain dans la boucle.
C’est crucial, car la plupart des projets « agentiques » échouent non pas parce que le modèle est mauvais, mais parce que personne n’a cartographié le parcours. L’agent se bloque à l’étape 4 parce que les données de l’étape 3 sont dans un système inaccessible pour lui. Ou l’étape 6 requiert une validation que personne n’a documentée. Ou le passage de relais entre l’agent et l’humain se fait via un canal Slack surveillé par un seul manager, mais par personne d’autre. La cartographie CUJ fait remonter tout cela avant la construction, ce qui coûte environ 200 fois moins cher que de le découvrir après coup.
Étape 3 : Construire — Prototypage no-code avec les bons outils
C’est à la troisième étape que les choses deviennent intéressantes, et là où Google fait un pari assez audacieux. La position du cadre est que le prototype doit être construit par l’équipe pluridisciplinaire qui a cartographié le CUJ — et non transmis à une équipe d’ingénierie pour interprétation. L’objectif d’utiliser des outils no-code comme Google AI Studio et Gemini Enterprise à ce stade est de garder les personnes les plus proches du processus aux commandes pendant que le système prend forme.
C’est la partie du cours qui vise directement les chefs de produit IA — le cadre explicite est qu’un PM doit pouvoir construire un prototype agentique fonctionnel sans ouvrir un seul ticket d’ingénierie. J’ai un avis mitigé là-dessus. D’un côté, j’ai vu trop d’initiatives IA en entreprise mourir dans l’écart entre la spécification du PM et l’interprétation qu’en fait l’ingénieur. Permettre au PM de construire directement le prototype comble cet écart, et le gain de vitesse est réel.
D’un autre côté, les prototypes no-code ont tendance à devenir des systèmes de production par accident. Ce qui a été construit en trois jours « pour prouver le concept » est présenté à la direction, la direction adore, et soudain, c’est en production avec toute la rigueur architecturale d’un hackathon du samedi après-midi. J’ai vu cela arriver avec des workflows Zapier, des apps Bubble, des automatisations Notion. Rien n’indique que les prototypes d’IA agentique y échapperont.
La discipline imposée par le cadre à l’étape trois est ce qui la sauve. Les prototypes sont explicitement conçus comme jetables — preuve de concept, pas production. L’objectif de l’étape est de valider que le CUJ tient la route lorsqu’un agent l’exécute réellement, que les chiffres d’ingénierie de la valeur étaient justes, et que les passages de relais humains fonctionnent. Une fois cela validé, on passe à l’étape quatre, où le véritable système de production est construit avec l’architecture, la sécurité et l’observabilité qu’exige la production.
Étape 4 : Déployer à l’échelle — L’étape dont personne ne veut parler
Le cours est honnête sur un point : l’étape quatre — déployer et opérer réellement des systèmes agentiques à l’échelle de l’entreprise — est celle dont le playbook est le moins mature. Tout le monde est encore en train d’apprendre. Les entreprises qui l’ont fait (et elles ne sont pas nombreuses) la traitent comme un programme pluri-trimestre impliquant des équipes plateforme, des cadres de gouvernance, l’observabilité des agents, et une politique claire sur les cas où l’autorité de décision d’un agent doit être remontée à un humain.
Les deux personnages que Clara utilise pour illustrer concrètement cette étape sont Beth, directrice de la stratégie d’une chaîne de distribution fictive appelée Symbol Mart, et Tomo, le responsable technique. Le rôle de Beth est de garder la transformation agentique alignée sur la valeur business et de s’assurer que les projets prioritaires font réellement bouger les indicateurs visés. Celui de Tomo est de garantir que les systèmes construits sont sécurisés, pragmatiques et suffisamment scalables pour survivre au passage du prototype au déploiement entreprise.
Ce binôme est essentiel. La raison pour laquelle la plupart des initiatives IA agentique échouent à l’étape quatre, c’est qu’elles sont portées exclusivement par l’un ou l’autre. Un leadership « Beth-only » produit de magnifiques slides et prototypes qui ne passent jamais à l’échelle. Un leadership « Tomo-only » produit des systèmes robustes qui automatisent des choses dont personne n’a réellement besoin. L’affirmation opérationnelle centrale du cadre est que le taux de réussite à l’étape quatre dépend de la solidité du couplage entre ces deux rôles tout au long de la transformation.
Voilà pour le cadre. Maintenant, laissez-moi vous dire où, selon moi, il se plie.
Ce qui fonctionne vraiment, et ce que je trouve surconçu
Je veux être prudent ici, car il est facile de lire un cadre Google et soit de s’y soumettre, soit de le rejeter. Les deux réactions sont paresseuses. Voici ce que je pense réellement après l’avoir expérimenté.
Le changement de mentalité à l’étape Discover est la pièce la plus importante, et la plus facile à négliger. Presque personne ne le fait correctement. Presque tout le monde aborde l’IA agentique en conservant le modèle de processus existant et en insérant des agents dans les étapes déjà en place. Le prix à payer pour avoir sauté l’exercice du « et si » est que vous passez un an à construire des agents qui rendent un processus voué à l’échec simplement un peu plus rapide.
La discipline d’ingénierie de la valeur à l’étape Design est l’élément que je vais reprendre intégralement et appliquer à mon propre travail, y compris sur des projets qui n’ont rien à voir avec l’IA agentique. Le principe se généralise : quantifiez la valeur avant de construire, nommez la personne dont le travail va changer, et refusez de lancer le projet tant que vous ne pouvez pas faire les deux. Je vais probablement écrire un article séparé rien que sur ce sujet, car il le mérite.
La cartographie CUJ est juste dans l’esprit mais un peu lourde en pratique pour tout ce qui est en dessous de l’échelle entreprise. Si vous êtes une startup de cinq personnes ou un constructeur solo, vous n’avez pas besoin d’un document CUJ formel. Vous devez simplement dérouler le flux de travail sur un tableau blanc et marquer les points de passage. Le formalisme du cadre s’adapte à la taille de l’organisation. Utilisez le principe, adaptez l’artefact à l’échelle.
L’accent mis sur le no-code à l’étape Build est pertinent pour les prototypes et dangereux pour la production. Traitez-le en conséquence. Le prototype est construit rapidement dans Google AI Studio, Gemini Enterprise ou quelle que soit votre stack. Le système de production, lui, doit être construit avec un vrai processus d’ingénierie. Ne laissez pas la démo devenir le déploiement.
L’étape Scale est celle où le cadre est honnête sur ses propres limites, et je respecte cela. Personne n’a encore de playbook pour une transformation agentique à l’échelle de l’entreprise. Ce que le cadre vous apporte, c’est la bonne structure organisationnelle — l’association Beth et Tomo, l’alignement sur la valeur, le pragmatisme technique. Les détails, vous devrez les découvrir en pratiquant.
Ce que le cadre ne dit pas explicitement, et devrait probablement : un nombre significatif de ces transformations vont échouer. Non pas parce que le cadre est mauvais, mais parce que le changement organisationnel nécessaire pour l’appliquer est réellement difficile. Laisser un agent prendre en charge un processus de bout en bout signifie que le travail de quelqu’un va changer. Parfois, ce changement est un enrichissement — la personne passe de l’exécution à la supervision du système. Parfois, c’est une suppression. Le cadre est un document de stratégie, pas un document de conduite du changement. Vous aurez besoin des deux.
Ce que cela signifie si vous construisez en ce moment
Si vous êtes développeur, le changement le plus utile consiste à arrêter de vous demander « quelle tâche puis-je automatiser avec un agent » et à commencer à vous demander « quel processus puis-je confier à un système autonome ». Ce n’est pas la même question, ce n’est pas la même architecture, et le plafond de valeur est radicalement différent. Les agents que vous construisez en partant de la seconde question valent environ 10 fois plus que ceux issus de la première, d’après mon expérience.
Si vous êtes chef de produit ou fondateur, la discipline de l’ingénierie de la valeur est la pratique à plus fort effet de levier que vous puissiez adopter ce trimestre. Avant de valider la prochaine fonctionnalité IA, écrivez en un paragraphe : qu’est-ce qui change concrètement pour l’entreprise si cela fonctionne, qui est la personne responsable de ce résultat aujourd’hui, et que devient son travail lorsque l’agent l’exécute efficacement. Si vous n’arrivez pas à rédiger ce paragraphe, la fonctionnalité n’est pas prête à être développée.
Si vous dirigez une entreprise e-commerce, la transition vers le commerce agentique n’est pas un problème pour 2030. C’est un enjeu pour 2026. Le fait que 70 % des consommateurs se disent à l’aise avec des achats pilotés par des agents signifie que l’agent d’achat intégré à ChatGPT ou Gemini décidera si votre produit apparaît ou non dans la sélection, bien avant que le client ne tape le nom de votre marque. Cela a des implications sur la structure des données produits, l’accessibilité via API, et la façon dont vous décrivez vos produits de manière lisible par les machines. Si vous concevez la page produit d’aujourd’hui pour l’acheteur humain de demain, vous construisez pour un acheteur qui est en train d’être discrètement remplacé.
Si vous êtes dirigeant d’entreprise, la dynamique Beth-et-Tomo est la partie à intégrer. Trouvez votre Beth. Trouvez votre Tomo. Faites-leur co-porter la transformation. Si l’un des deux manque ou est mis à l’écart, le programme produira quelque chose — des slides ou des systèmes — mais il ne produira pas de transformation.
Remarque sur la promesse du no-code
Il y a un aspect du cadrage du cours sur lequel je souhaite apporter une nuance. La promesse selon laquelle les chefs de produit IA peuvent construire des systèmes agentiques de qualité production sans ingénieurs est, à mon sens, partiellement vraie et dangereusement séduisante.
La part de vérité : les chefs de produit peuvent effectivement créer des prototypes qui valident le CUJ, démontrent la valeur et illustrent le workflow. C’est réel, et c’est un véritable levier. La part dangereusement séduisante : l’écart entre un prototype fonctionnel et un système de production capable de gérer la sécurité, la montée en charge, la reprise sur erreur, l’observabilité, la conformité, et tous les cas limites qui apparaissent après 73 heures de fonctionnement continu est immense. C’est précisément là que réside l’ingénierie. Le no-code ne comble pas cet écart. Il accélère la création du prototype, ce qui est précieux. Considérez-le comme tel.
La bonne façon d’interpréter l’accent mis par Google sur le no-code n’est pas « les ingénieurs ne sont plus nécessaires pour l’IA agentique ». C’est plutôt : « la phase de prototypage n’a plus besoin d’attendre la disponibilité des ingénieurs, ce qui permet de valider plus d’idées plus rapidement, et donc de consacrer la capacité d’ingénierie aux prototypes qui ont prouvé leur valeur ». C’est une affirmation bien plus modeste, et c’est celle qui me semble réellement tenir la route.
Ce que je fais différemment cette semaine
Pour revenir à la dispute du dimanche matin avec laquelle j’ai commencé — celle où j’ai réalisé que j’avais construit sept agents et zéro workflow — j’ai passé la journée d’hier à en repenser un.
Le scraper de tarification concurrentielle devient un système de tarification concurrentielle. Il extrait toujours les données. Mais désormais, il évalue si l’écart de prix est pertinent au regard de notre seuil de marge, rédige une proposition de modification tarifaire, m’envoie une demande d’approbation en une ligne avec la justification, puis, après validation, applique le changement et surveille la conversion pendant 72 heures avant de maintenir ou d’annuler la modification. Le travail que je faisais auparavant — analyser les données, décider, exécuter, surveiller — est désormais structuré par le système. Mon rôle se limite à approuver ou rejeter la proposition. C’est un processus, pas une tâche.
Il m’a fallu environ quatre heures pour le repenser. Je pense qu’il me fera économiser quatre heures par mois, indéfiniment. La version agent me faisait gagner quarante minutes par semaine. La version workflow m’économise une demi-journée. Même modèle, mêmes données, mêmes outils — mais une question différente posée lors de la conception.
C’est à cela que sert réellement le framework. Pas à rédiger de meilleures présentations sur la stratégie IA. À vous pousser à poser une question différente au moment où toute l’architecture de ce que vous construisez se décide.
Choisissez une chose cette semaine que vous avez déjà « IA-ifiée » en tant que tâche. Posez-vous la question du « et si ». Demandez-vous si un système agentique pourrait prendre en charge l’ensemble du processus plutôt qu’une seule étape. Si la réponse est oui, repensez-le. Si la réponse est non, demandez-vous pourquoi — car ce « non » pointe généralement vers la véritable contrainte, et la véritable contrainte est souvent un passage de relais humain que personne n’a pris la peine de cartographier.
C’est cela, plus que n’importe quel framework, qui fait la différence.
Foire Aux Questions
Quelle est la différence entre un agent IA et un système IA agentique ?
Un agent IA exécute une tâche unique ; un système IA agentique gère de manière autonome l’ensemble d’un processus à travers plusieurs étapes, décisions et relais. L’agent est un outil intégré dans un flux de travail encore humain. Le système agentique remplace le flux de travail lui-même. Pour une distinction approfondie avec des exemples, consultez la section ci-dessus sur les agents versus les workflows.
Quelles sont les quatre étapes du cadre de transformation IA agentique de Google ?
Les quatre étapes sont Découvrir (changement de mentalité du statu quo vers le « et si »), Concevoir (ingénierie de la valeur et cartographie du Critical User Journey), Construire (prototypage sans code avec des outils comme Google AI Studio et Gemini Enterprise), et Déployer à l’échelle (opérationnalisation des systèmes agentiques à l’échelle de l’entreprise). L’ordre est crucial — ignorer la phase Découvrir est la cause d’échec la plus fréquente.
Qu’est-ce que le commerce agentique et pourquoi est-ce important en 2026 ?
Le commerce agentique désigne l’e-commerce réalisé par des agents IA agissant au nom des acheteurs humains — une expérience d’achat « zéro clic » où l’agent découvre, évalue et achète sans que l’utilisateur ne visite de site web. eMarketer prévoit 20,9 milliards de dollars de ventes e-commerce pilotées par des plateformes IA en 2026, soit environ 4 fois plus qu’en 2025, et McKinsey anticipe 1 000 milliards de dollars d’ici 2030.
Qu’est-ce qu’un Critical User Journey (CUJ) dans la conception IA agentique ?
Un Critical User Journey cartographie le parcours utilisateur de bout en bout (ou celui de l’agent agissant pour lui) pour atteindre un résultat significatif, en identifiant chaque décision, dépendance de données et relais. La cartographie CUJ met en lumière les lacunes opérationnelles qui font échouer les projets agentiques — accès aux données manquant, validations non documentées, relais défaillants — avant même l’écriture de la moindre ligne de code.
Les chefs de produit IA peuvent-ils construire des systèmes agentiques sans ingénieurs grâce aux outils no-code ?
Partiellement. Les chefs de produit peuvent créer des prototypes validés à l’aide d’outils comme Google AI Studio et Gemini Enterprise, ce qui accélère considérablement le processus. Mais passer d’un prototype fonctionnel à un système de production capable de gérer la sécurité, la montée en charge, la reprise sur erreur et l’observabilité nécessite toujours des ingénieurs. Le bon cadrage est un prototypage plus rapide, pas un remplacement de l’ingénierie.
Travaillons ensemble
Vous souhaitez créer des systèmes d’IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous accompagner.
- Fiverr (développements sur mesure & intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions pour entreprises) : ramlit.com
- ColorPark (design & branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
