Résumé et synthèse :

En Première partie, nous avons montré comment l'IA d'entreprise stagne au niveau d'adoption 14% lorsqu'elle est achetée sous forme de SaaS. Dans Partie 2, nous avons répertorié les quatre capacités de la couche de déploiement (Déploiement, Ancrage, Adoption, Développement) et démontré pourquoi l’ancrage doit précéder la formation. Dans la troisième partie, nous présentons la structure opérationnelle nécessaire pour garantir la pérennité de cette approche : des équipes intégrées réunissant des stratèges et des ingénieurs, le chaos qui règne en leur absence, ainsi que les preuves concrètes tirées de Chancerygate.

Si la couche de déploiement est mise en place par des personnes plutôt qu’achetée sous forme de produit, la question est alors de savoir quelles personnes et comment elles sont organisées. Ma réponse s’inspire délibérément de la manière dont les laboratoires eux-mêmes travaillent avec leurs plus gros clients, et c’est une réponse que la plupart des cabinets de conseil, y compris le mien jusqu’à récemment, n’étaient pas structurés pour apporter : de petites équipes, intégrées, responsables d’un résultat plutôt que d’un livrable. Trois verbes permettent de décrire cette approche.

Intégrer

Associez un stratège en mission sur le terrain à un ingénieur en mission sur le terrain et affectez-les tous les deux au sein même de l'entreprise du client, physiquement si possible, pendant toute la durée de la mission.

  • Le stratège est responsable des résultats commerciaux et du modèle opérationnel : quels processus, quels services prioritaires, lesquels parmi les quatre-vingts cas d'utilisation figureront dans la feuille de route de la première année, comment le bureau dédié à l'IA sera doté en personnel, comment la valeur sera mesurée et communiquée au comité de direction.
  • L'ingénieur dispose de la plateforme, de la couche contextuelle et des agents : le serveur MCP et ses connecteurs, le modèle d'autorisation, l'infrastructure des agents, ainsi que l'intégration avec tout ce que le client utilise déjà.

Au cours d’une semaine type, le stratège se trouve dans le bureau du directeur financier le matin, tandis que l’ingénieur travaille en binôme avec l’équipe data du client l’après-midi ; tous deux participent ensuite à la même réunion debout. Aucun des deux ne s’appuie sur une présentation PowerPoint, et aucun n’est autorisé à laisser une recommandation comme livrable. Le résultat attendu, c’est le produit qui fonctionne.

Je suis convaincu que le binôme importe davantage que l'ancienneté. À lui seul, un stratège élabore une feuille de route qui reste en attente de l'informatique. À lui seul, un ingénieur développe une plateforme qui reste en attente de la direction. Ensemble, ils instaurent une habitude du lundi matin.

Train

La mise en œuvre s'effectue service par service, sur le système data en production, et il s'agit davantage d'un transfert de responsabilité que d'une simple livraison. Trois rôles sont essentiels pour garantir sa pérennité :

  1. Champions de l'IA dans chaque secteur d'activité, choisis davantage par curiosité que pour leur titre, qui organisent des permanences hebdomadaires, recueillent les questions auxquelles l'outil n'a pas pu répondre et transmettent les nouveaux cas d'utilisation à l'équipe.
  2. Un bureau dédié à l'IA au cœur de la structure, avec quatre fonctions : la direction et la gouvernance, qui gèrent le portefeuille et les licences ; une équipe chargée des cas d'utilisation, qui se consacre au développement ; une équipe chargée de la plateforme, qui gère la couche contextuelle, la sécurité et les outils de base ; et une fonction dédiée à l'adoption, en collaboration avec les RH, qui gère la formation et la gestion du changement.
  3. Accompagnement technique pour les équipes techniques travaillant sur Claude Code et Codex — hackathons, permanences, groupe de travail sur la gouvernance chargé des questions d’accès et de coûts —, mesurées en nombre de sessions quotidiennes par développeur plutôt qu’en nombre de places.

Le critère que j'applique est simple : si l'équipe déployée sur le terrain venait à disparaître demain, l'utilisation continuerait-elle d'augmenter ? Si ce n'est pas le cas, cela signifie que rien n'a encore été adopté.

Construire

Les agents sont livrés au rythme de sprints de deux semaines. Le premier jour consiste en un atelier pratique intitulé “ Comment créer un agent ”, organisé avec les responsables du processus, de sorte qu’à l’heure du déjeuner, le comptable chargé des comptes fournisseurs ait vu une facture transformée en champs structurés et sache ce que l’agent fera et ne fera pas. Le reste du sprint est consacré au développement, aux tests et aux itérations sur des documents réels, avec une démonstration destinée aux services opérationnels le dernier jour.

Chaque agent repart avec une infrastructure réutilisable — dans un environnement Microsoft, il s’agit généralement de flux Power Automate qui importent les documents et appellent l’API Claude à l’aide du schéma et des documents de référence, renvoyant ainsi un dossier structuré destiné à être examiné par un humain — ainsi que des modèles de prompts, de courtes vidéos, le nom d’un responsable métier, d’un utilisateur test et d’un responsable de la maintenance qui a suivi de près la mise en place du système.

La mesure du succès ne réside pas dans les quatre agents que nous livrons. Elle réside dans les vingt que le client développe par la suite sans notre aide. Si ce chiffre est égal à zéro, cela signifie que nous avons créé une dépendance, et non une capacité.

La relation avec les laboratoires est un fil conducteur commun à ces trois aspects. Je pense que la couche de déploiement ne fonctionne que si les personnes qui la développent ont une visibilité sur la feuille de route à six mois, peuvent s’adresser directement à l’équipe des solutions du laboratoire lorsqu’un connecteur présente un dysfonctionnement, et peuvent réunir les ingénieurs du laboratoire dans la même pièce que les dirigeants et les développeurs du client. Cette proximité n’est pas une simple courtoisie commerciale. C’est ce qui permet à un déploiement d’intégrer MCP, Skills, Cowork ou Codex dès le mois de leur sortie, plutôt que l’année suivante.

Quels problèmes cela pourrait-il poser sans cela ?

Imaginez ce même DSI dans dix-huit mois, après avoir renouvelé les postes et fait l'impasse sur la couche de déploiement.

Le nombre d’utilisateurs a atteint trois mille ; le taux d’utilisateurs actifs n’a pas évolué. Les employés qui en voulaient davantage ont discrètement transféré leur véritable travail vers des comptes personnels, où les projets de contrats de l’entreprise, les listes de clients et les prévisions pour l’année prochaine se retrouvent désormais dans des historiques de discussion que personne ne contrôle et que personne ne peut supprimer. Trois services ont chacun acquis une solution ponctuelle dotée de son propre modèle intégré, de ses propres connecteurs et de ses propres autorisations — une pour la révision des contrats, une pour le service client, une pour les achats — dont aucune ne s’accorde sur la définition d’un client ou d’une marge, et dont chacune nécessite désormais son propre audit de sécurité.

Une poignée de passionnés ont créé eux-mêmes des agents, à l’aide d’un outil « no-code », en l’espace d’un week-end. Certains sont performants. Aucun ne dispose d’un responsable, d’un utilisateur test ou d’un journal d’activité, et l’un d’entre eux envoie des rappels de paiement aux fournisseurs en utilisant les coordonnées bancaires de l’année dernière. L'équipe de sécurité, alertée trop tardivement et confrontée à un environnement qu'elle n'a pas conçu, réagit de la seule manière dont elle le peut : en verrouillant tout, ce qui renvoie les passionnés vers leurs comptes personnels et l'organisation à la case départ.

L'équipe chargée des comptes du laboratoire constate qu'un client présente une utilisation stable, ne dispose d'aucun cas de référence et n'a aucun interlocuteur technique à qui s'adresser ; elle affecte donc ses ingénieurs en solutions, dont les ressources sont limitées, à un autre client. L'entreprise a payé pour une solution de pointe et s'est retrouvée avec un chatbot.

Je tiens à être précis quant à l'attribution des responsabilités dans ce domaine, car celles-ci sont généralement mal attribuées. Rien de tout cela ne relève d'un échec de la technologie, et très peu relève d'un échec des employés. C'est le résultat prévisible du fait de considérer une capacité comme un simple achat, et du fait que personne n'est tenu responsable de l'écart entre une licence et une habitude.

Ce que nous avons décidé de faire à ce sujet

Je terminerai en expliquant ce que cette conviction a signifié concrètement, car une opinion qui ne modifie pas votre façon de vous organiser n'est qu'un simple commentaire.
Chez Artefact, nous avons cessé de considérer le déploiement comme une simple étape à la fin d'une mission stratégique et en avons fait une discipline à part entière, dotée de sa propre équipe. Nous l'appelons DeployCo: des ingénieurs et des stratèges déployés sur le terrain, dont la seule mission concerne la couche de déploiement, travaillant en collaboration avec Anthropic et OpenAI, organisés par laboratoire et par région à travers l’Europe, le Moyen-Orient et l’Afrique, chaque région disposant d’un responsable commercial et d’un responsable technique pour chaque laboratoire. Nous avons l’intention d’en compter une centaine d’ici 2027. C’est un pari, et je n’hésite pas à l’affirmer publiquement car je pense que l’alternative — vendre une stratégie et laisser à d’autres le soin de s’occuper des aspects techniques — est précisément ce qui a conduit le secteur à atteindre 14%.

Ce pari repose sur quelques convictions auxquelles je tiens fermement :

  • Cet ancrage doit toujours précéder l'entraînement, et une séance d'entraînement qui ne tient pas compte du data propre au client n'est que de la comédie.
  • Un agent dont le propriétaire et le responsable de la maintenance ne sont pas clairement identifiés constitue un risque, et non un atout, aussi performant soit-il.
  • L'équipe du client doit réaliser davantage de projets que la nôtre en l'espace d'un trimestre, sinon nous aurons échoué.
  • Et que les personnes qui mènent ces travaux doivent être suffisamment proches des laboratoires pour anticiper les évolutions à venir ; c’est pourquoi nous passons notre temps dans des salles avec elles — rien qu’en octobre, à Munich, à Zurich et à Casablanca, avec d’un côté de la table les dirigeants de nos clients et leurs développeurs, et de l’autre les équipes d’Anthropic et d’OpenAI, à travailler sur des déploiements concrets plutôt qu’à écouter des discours d’ouverture.

Chancerygate, un promoteur immobilier industriel et gestionnaire d'actifs londonien comptant environ 700 locataires et gérant quelque 1,2 milliard de livres sterling, est pour moi la preuve la plus évidente que la troisième hypothèse est fondée. Un atelier organisé au printemps avait mis en évidence les freins habituels liés aux tâches administratives : une centaine de factures fournisseurs par mois ressaisies à la main, une heure et demie pour valider le procès-verbal de chaque grande réunion, des examens des accords de confidentialité (NDA) présentant des incohérences dans la couverture des clauses de risque, des modèles de souscription élaborés en recopiant des chiffres à partir de fichiers PDF.

Au cours d'un sprint de deux semaines au sein de leur environnement Microsoft, une équipe conjointe a mis au point quatre agents basés sur Claude pour répondre précisément à ces quatre problèmes :

  1. Comptabilité fournisseurs: 80% de temps en moins par facture, plus de 90% de lignes de facture mises en correspondance automatiquement.
  2. Analyse de la NDA: de trois jours à moins de deux heures.
  3. Initialisation de la souscription: de 25 heures à moins de trois.
  4. Compte rendu de réunion: une heure et demie à trente minutes.

Chacun d’entre eux a été confié à un responsable, un utilisateur test et un chargé de maintenance. Depuis lors, leur propre équipe — composée d’environ 25 personnes formées, dont une dizaine utilise les agents quotidiennement — a développé plus de vingt agents supplémentaires, chacun en moins d’une demi-journée, et procède actuellement à l’intégration directe de l’agent AP dans NetSuite et de l’agent NDA dans DocuSign. “ L'équipe Artefact a été formidable ”,” dit Phil Price, leur responsable FP&A, et “ nous a mis en bonne position pour continuer à nous développer et à nous étendre par nos propres moyens. ” La première partie de cette phrase est bienveillante. C'est la seconde partie qui va droit au but.

La frontière n'est plus le modèle. C'est la distance qui sépare le modèle de votre lundi matin. Si vous disposez de licences Claude ou ChatGPT et que vous ne pouvez pas encore répondre aux trois questions posées dans cet article — ce que le modèle sait de vous, qui est responsable de la mise en œuvre dans chaque service, et qui développe et assure la maintenance de vos agents —, alors vous ne disposez pas encore d'une capacité d'IA. Vous disposez d’un abonnement.

La bonne nouvelle, c'est que cet écart peut être comblé en quelques semaines, et non en plusieurs années, par des personnes qui ont décidé que c'était leur mission de le combler.

Je serais ravi de savoir sur quels points vous n'êtes pas d'accord : remi.sabonnadiere@artefact.com