Votre agent ne vaut que ce que vaut le processus derrière lui.

Dans l’Épisode 1, Naomi nous montrait où la plupart des agents IA échouent : avant même que le développement ne commence. La question est maintenant : quelle est l’étape suivante ? Et pourquoi presque tout le monde se trompe-t-il exactement au même endroit ?

Un point de ce premier épisode me revient sans cesse : la plupart des agents IA échouent à la naissance, pas au moment de la construction. Ils s’effondrent parce que leur ADN – le problème, la décision, la donnée, la valeur – n’a jamais été clairement défini.

Si vous lisez ce deuxième article, partons du principe que vous avez fait ce travail. Vous connaissez le problème que votre agent doit résoudre. Vous savez quelles décisions il doit appuyer. Vous avez le soutien de votre direction.

Et maintenant ?

La plupart des équipes sautent directement en mode « solution » : catalogue de modèles ouvert, framework choisi, premier prototype d’ici vendredi.

C’est exactement là que l’erreur commence. Le passage à la technologie intervient beaucoup trop tôt.

La technologie est la partie facile.

La stack IA en 2026 s’est commoditisée. Modèles de pointe, frameworks d’agents, couches d’orchestration, vector stores, outils d’évaluation. Tout cela est disponible, bien documenté et largement interchangeable.

Créer un agent fonctionnel rapidement n’est plus un élément différenciateur. Votre concurrent peut faire la même chose. Un partenaire compétent ailleurs aussi. La vitesse seule ne crée pas un avantage concurrentiel durable.

Ce que personne ne peut copier, en revanche, c’est votre processus métier.

C’est là que réside votre expertise du domaine. C’est là que se trouvent des années d’expérience, des décisions implicites et un jugement durement acquis. En d’autres termes : c’est là que réside la valeur réelle de votre entreprise.

Une chose sur laquelle il vaut la peine d’être honnête dès le départ, automatisez un mauvais processus et vous obtenez un mauvais processus, désormais plus rapide et appuyé par l’IA. Le résultat est toujours mauvais. Seule la confiance qui l’entoure augmente.

C’est pourquoi cet épisode ne parle pas de frameworks, mais de ce que personne ne veut prendre le temps de faire : détailler le processus métier, de bout en bout.

Le plan d’un agent vit dans le processus, pas dans le code.

Lorsque nous démarrons un projet avec un client, nous ne commençons pas par des schémas d’architecture. Nous commençons par un logigramme (flowchart).

Un exemple récent dans le secteur manufacturier : le client voulait un agent pour accélérer la création de plans de processus de production. Demande raisonnable, problème clair, vraie valeur à la clé.

Avant une seule ligne de code, nous avons cartographié le processus :

• • Développement produit terminé. Qu’est-ce qui déclenche le passage de relais ?
  • Informations de processus ajoutées. Par qui, depuis quel système, à quel niveau de détail?
  • Statut du produit défini. Quelles sont les transitions valides, qui en est le propriétaire ?
  • Phase prototype, phase MVP, série. Quelles décisions diffèrent selon la phase ?
  • Quels systèmes détiennent les données de référence, lesquels sont en lecture seule, lesquels sont officiellement utilisés et lesquels sont réellement utilisés ?
  • Quels acteurs participent, et lesquels disent seulement le faire ?

Une fois cette cartographie terminée, il se produit quelque chose qui surprend les clients à chaque fois : l’agent est déjà visible sur le tableau blanc.

Mais ce n’est pas tout. La même carte expose toutes les opportunités adjacentes :

• • Le savoir qui résidait dans la tête d’une personne est capturé au fil de l’exécution du processus et enfin pérennisé comme connaissance d’entreprise.
  • Les rapports d’audit deviennent des sous-produits naturels du flux, et non une urgence trimestrielle distincte.
  • Les passages de relais entre départements deviennent traçables.
  • La justification de la prochaine amélioration de processus se trouve déjà dans les données.

C’est là qu’un processus métier se transforme en « machine à penser ». Pas grâce à un agent héroïque unique, mais grâce à de nombreuses petites décisions de conception délibérées qui s’additionnent. C’est là que la vraie valeur créative est générée

Pas de qualité de données, pas d’agent. Point.

Une fois le processus cartographié, nous posons une question très simple à chaque étape : sur quelles données repose cette décision, et pouvons-nous leur faire confiance ?

La réponse, plus souvent qu’on ne le voudrait, est non :

• • La donnée existe, mais dans trois systèmes parallèles non alignés.
  • La donnée est saisie, mais seulement quand quelqu’un s’en rappelle.
  • La donnée est techniquement disponible, mais personne dans l’équipe opérationnelle ne l’utilise.
  • La donnée est utilisée, mais personne ne garantit sa qualité.

Une couche d’IA agentique ne réglera rien de tout cela. Elle va l’amplifier. Un agent sûr de lui qui prend des décisions sur des données incohérentes est pire que pas d’agent du tout, car il est plus rapide et bénéficie de plus de confiance que les humains qu’il est censé soutenir.

L’IA agentique amplifie la fondation de données sur laquelle elle repose. Des données gouvernées, de haute qualité et accessibles ne sont pas un « plus nice-to-have » : c’est le mur porteur de tout agent performant.

C’est pourquoi la préparation des données (data readiness) n’est pas un chantier parallèle qui tourne en même temps que le développement. C’est un prérequis. Responsabilité (ownership), qualité, accès, cycle de vie : tout doit être catalogué, surveillé et amélioré en continu. Si un client n’est pas prêt à faire ce travail, nous le disons dès le premier jour. Cela évite à tout le monde des mois douloureux et des budgets gaspillés.

La bonne nouvelle : la cartographie du processus nous indique déjà exactement par où commencer. Pas besoin d’essayer de résoudre tous les problèmes à la fois : il suffit de corriger les données aux points de décision stratégiques.

Pourquoi notre ingénierie ressemble à de l’exécution, pas à de l’invention

Rien de tout cela n’est théorique. Nous faisons cela depuis assez longtemps pour avoir accumulé des cicatrices, des schémas récurrents et un vrai parti pris.

Au fil de nombreux projets, nous avons appris à travailler de manière itérative et agile avec nos clients pour arriver au bon résultat : de petites incrémentations, du feedback utilisateur réel, des points d’étape honnêtes, des corrections de trajectoire sans ego. C’est un muscle. Il ne se développe pas dans un atelier, mais sur le terrain, lors de la livraison.

De cette expérience, nous avons façonné un framework évolutif où les pièces du puzzle s’assemblent parfaitement tout en s’adaptant au processus et au besoin métier :

• • Le modèle est un choix parmi d’autres, pas Le choix unique. Il peut être changé selon le cas d’usage, les contraintes ou le profil de coût.
  • La couche de données, les outils et les intégrations sont tout aussi modulaires. Rien dans l’architecture ne bloque le client dans un coin.

Le résultat offre deux choses essentielles simultanément : la souveraineté (le client garde le contrôle sur ses données, son processus et sa feuille de route) et la flexibilité.

C’est cette combinaison qui transforme le constat « Nous avons créé un agent » en « Nous pouvons créer, faire évoluer et passer à l’échelle un portefeuille d’agents. » La discussion avec le DAF devient alors totalement différente.

Et puis… la facture arrive

L’IA est devenue une commodité. Elle est intégrée dans presque tous les processus d’entreprise, et de plus en plus via des agents. Mais presque toujours, la facture arrive à la fin.

Les entreprises observent désormais ce que coûte réellement une véritable adoption :

• • Consommation de tokens pour les appels aux LLM.
  • Puissance de calcul pour l’orchestration.
  • Stockage et transfert à travers un paysage de données en constante expansion.
  • Intégration dans des systèmes en amont et en aval qui n’ont jamais été conçus pour ce type de trafic.

Tout cela augmente avec l’usage – et l’usage est précisément ce que nous cherchons à développer.

C’est là que la question vérité surgit en comité de direction :

« C’est très bien d’apporter toutes ces efficiences dans l’entreprise. Mais à quel prix ? Le business case tient-il toujours ? Et les gains d’efficacité se traduisent-ils réellement par de la valeur concrète – plus de chiffre d’affaires, de meilleures marges, un volume produit plus élevé – ou sommes-nous juste en train de payer un nouveau prestataire pour ce que nos équipes faisaient auparavant ? »

Ces questions doivent être posées dès le premier jour. Pas après le pilote. Pas après le déploiement. Dès l’étape du tableau blanc.

Cela signifie qu’il faut orienter la conception de l’agent vers sa contribution réelle à la valeur, et vers une structure de coûts qui reste proportionnelle. C’est ici que notre framework flexible prend tout son sens.

Si l’architecture le permet, nous pouvons utiliser des modèles plus petits et moins chers pour les nombreuses étapes de raisonnement quotidiennes (classification, routage, étapes intermédiaires) et réserver les grands modèles coûteux uniquement pour les moments où ils apportent une vraie valeur ajoutée. Ce seul choix de conception peut modifier l’équation économique d’un agent d’un ordre de grandeur, sans altérer son résultat métier.

L’efficience dans le flux même de l’agent n’est pas une optimisation que l’on fait plus tard : elle fait partie intégrante de ce qui permet au business case de survivre à la réalité.

L’intégration native bat l’option « L’IA par-dessus »

Le troisième élément différenciateur est celui qui se perd le plus facilement dans un pitch.

Un agent performant n’est pas « plaqué » sur l’environnement d’outils existant. Il est ancré au cœur du processus qu’il automatise. L’utilisateur ne « va » pas vers l’agent. L’agent apparaît là où le travail se fait déjà : dans l’écran ERP, dans l’outil d’ingénierie, dans la fiche CRM, dans le canal Teams où la décision est prise de toute façon.

Cela ressemble à un détail technique. Ça ne l’est pas. C’est un choix de modèle opérationnel.

L’approche « L’IA par-dessus » vous donne une simple fonctionnalité. Les utilisateurs l’essayent, l’aiment en démonstration, et l’oublient dans leur travail quotidien. L’intégration native vous donne une nouvelle façon d’exécuter le processus. C’est là que les chiffres de productivité finissent par apparaître, et c’est ce qui sépare un pilote dont on est fier d’une valeur réelle déployée à l’échelle.

Si votre cible est simplement une fenêtre de chat à côté de vos outils existants, vous n’avez pas construit un agent. Vous avez construit un raccourci.

Où tout cela nous mène

1. 1. Concevez le processus.
   2. Corrigez les données.
   3. Construisez avec un framework qui garantit votre souveraineté et la maîtrise de vos coûts.
   4. Ancrez l’agent là où le travail a lieu.

Faites cela, et la technologie deviendra véritablement la partie facile. Sautez l’une de ces étapes, et aucun modèle du marché ne sauvera votre projet.

Dans l’Épisode 3, notre équipe Conduite du Changement prendra le relais des ingénieurs : comment amener les équipes à utiliser réellement un agent performant une fois déployé ? Parce qu’un agent bien conçu que personne n’adopte reste un projet en échec.

Prêt à cartographier le processus derrière votre agent ? Réservez une session de 30 minutes avec l’équipe d’Oliver pour identifier où votre projet réussira ou bloquera, avant même d’avoir écrit la moindre ligne de code.