Introduction

Il y a quelques mois, un directeur informatique m'a montré son tableau de bord Claude Enterprise. Deux mille postes, déployés en six semaines, une authentification unique via le fournisseur d'identité de l'entreprise, une politique d'utilisation validée par le service juridique et acceptée par chaque collaborateur lors de sa première connexion. Puis il est passé à l'onglet suivant. Nombre d'utilisateurs actifs hebdomadaires : 14%.

La demande la plus courante : “ Résumez cet e-mail. ” La deuxième plus courante : “ Réécrivez ce texte dans un style plus professionnel. ” Aucune connexion à l'ERP, à l'entrepôt data ou aux référentiels de documents. Pas un seul agent en production. Trois étages plus bas, l'équipe chargée des comptes fournisseurs ouvrait les fichiers PDF des fournisseurs un par un, relevait le numéro de facture, le montant et le centre de coûts, puis les saisissait manuellement dans le système comptable — soit environ un une centaine de factures par mois, ce qui représente environ un jour et demi de travail pour une personne.

Cela ne me surprend plus. Je pense désormais que c'est le résultat inévitable de la manière dont les entreprises achètent des solutions d'IA, et je tiens à vous expliquer sans détours pourquoi.

Nous avons décidé collectivement de traiter les modèles de pointe comme des logiciels : acquérir la licence, attribuer les postes, organiser un webinaire, puis passer à autre chose. Cela a fonctionné pour la messagerie électronique et pour le CRM, car la valeur de ces outils résidait dans l’outil lui-même : la boîte de réception était le produit, la vue du pipeline était le produit. La valeur d'un modèle « frontier » ne réside pas dans le modèle lui-même. Elle réside dans l'écart entre ce modèle et le data, les autorisations, les habitudes et les processus d'une entreprise donnée.: si le modèle permet de consulter les ventes du dernier trimestre par référence, s'il tient compte du fait que le “ chiffre d'affaires net ” de cette entreprise exclut les dépenses commerciales, si une directrice des ventes l'a déjà utilisé ne serait-ce qu'une seule fois pour répondre à une question à laquelle elle devait effectivement répondre cette semaine-là.

Personne au sein de l'organisation n'est rémunéré pour combler cet écart. Le service informatique est responsable de l'infrastructure et mesure la disponibilité. L'entreprise est responsable des cas d'utilisation et ne mesure rien. Le fournisseur est responsable de la feuille de route et mesure le nombre de licences. L'espace intermédiaire n'appartient à personne, et C'est dans cet espace que réside la valeur.

Après avoir passé une année à m'introduire dans des entreprises au moment « 14% », je suis convaincu que Cet espace constitue une discipline à part entière. Il ne s’agit pas d’une gestion du changement avec de meilleures présentations, ni d’une intégration de systèmes via une nouvelle API. Il s’agit d’un travail conjoint d’ingénierie, de data, de sécurité et d’adoption, mené au sein même du client, par des personnes qui s’inscrivent également dans la feuille de route du laboratoire et qui sont responsables d’un résultat plutôt que d’un livrable. J’appelle cela la « couche de déploiement », et cet article expose les raisons pour lesquelles elle revêt une importance bien plus grande que la prochaine version du modèle.

Pourquoi la mise en œuvre de l'IA en entreprise marque le pas une fois le contrat signé

Le schéma est le même dans le secteur bancaire, celui des biens de consommation, de l’immobilier et des télécommunications, et il se déroule selon une séquence reconnaissable. Un projet pilote aboutit : une petite équipe au sein du marketing ou du service client, un parrain bienveillant, un cas d’utilisation clair, une démonstration qui captive l’attention du comité de direction. Un deuxième projet pilote aboutit dans un autre service. La direction approuve un déploiement à l’échelle de l’entreprise, souvent avec un objectif du type “ L’IA pour tous d’ici le deuxième trimestre ”. Le déploiement a lieu. L'adoption augmente pendant trois semaines grâce à l'effet de nouveauté, puis se stabilise grâce à l'amélioration du moteur de recherche, et les agents qui devaient assurer le suivi du déploiement figurent toujours sur une diapositive intitulée “ Phase 2 ”.”

Les explications habituelles sont erronées.

  • Ce n'est pas que les employés s'opposent au changement ; Ceux que je rencontre ont désespérément besoin que cet outil leur permette de travailler sur leur tâche réelle et sont frustrés qu'il ne puisse pas détecter la feuille de calcul qu'ils consultent.
  • Ce n'est pas que les modèles soient encore peu aboutis ; Ils étaient déjà capables de faire la plupart de ces choses il y a deux générations, et l'écart entre ce dont Claude ou GPT sont capables et ce que l'organisation attend d'eux n'a fait que se creuser depuis.
  • Et ce n'est pas faute de cas d'utilisation. À chaque atelier que j'ai animé, on en a entendu quatre-vingts en une matinée, dont la moitié étaient des variantes de “ Arrêtez de me faire retaper ça ”.”

Le système se bloque car trois questions n'ont pas de responsable :

  • Que sait le modèle à notre sujet ? Quels systèmes peut-il consulter : l'entrepôt, les archives de documents, le système de billetterie, la plateforme RH ? Sous quelles autorisations les consulte-t-il : celles du compte de service ou celles de la personne qui en fait la demande ? Et lorsqu'il fournit un numéro, n'importe qui peut-il remonter jusqu'à la table ou au document d'où il provient ?
  • Qui est responsable de la mise en œuvre dans chaque service ? Il ne s'agit pas du nombre de licences, mais de l'habitude, dès le lundi matin, d'utiliser cet outil dans le cadre du travail quotidien des services commerciaux, financiers, juridiques et opérationnels, qui ont chacun leur propre data, leur propre vocabulaire et leur propre définition de ce qui est “ utile ”.”
  • Qui se charge de la mise en place des agents, et qui assure leur maintenance lorsque les consultants partent ? Un carnet de commandes informatiques qui s'étend déjà sur dix-huit mois, un prestataire externe sous contrat « temps et matériel », ou des collaborateurs issus de l'entreprise qui maîtrisent le processus qu'ils automatisent ?

Je n'ai encore jamais vu de programme aboutir lorsque ces questions ont été traitées par un comité de pilotage. Elles sont traitées par les personnes qui effectuent le travail, au sein même de l'entreprise, et qui disposent du pouvoir de décision.

La couche de déploiement : la capacité que personne ne prévoit dans son budget

Entre le modèle et l'entreprise se trouve une couche de travail qui n'est ni purement informatique, ni purement liée à la gestion du changement. Je la divise en quatre parties, et j'ai une opinion bien arrêtée sur chacune d'entre elles.

Déployer. La plateforme elle-même — Claude Enterprise, Claude Code et Cowork, ou ChatGPT Enterprise et Codex — a été déployée comme prévu. Concrètement, cela se traduit par un modèle de licence qui attribue les licences en fonction du rôle, du domaine d’activité et de l’ancienneté, plutôt que selon le principe du « premier arrivé, premier servi » ; une authentification via le SSO d’entreprise avec un accès par groupe ; une politique d’utilisation qui précise en langage clair ce qu’il est permis ou non de copier-coller, ainsi qu’un guide des bonnes pratiques décrivant les comportements à adopter ; et une gouvernance des coûts qui indique, par service, qui utilise quoi, dès la première semaine. C'est l'aspect que la plupart des organisations maîtrisent assez bien, mais c'est aussi celui qui, pris isolément, a le moins de valeur. Un tenant parfaitement configuré, mais auquel rien n'est connecté, revient très cher pour ce qu'il n'est qu'une simple fenêtre de discussion.

Sol. La couche contextuelle qui permet au modèle de fournir des réponses conformes à la réalité propre à l'entreprise. Concrètement : un serveur MCP unique, fonctionnant dans le tenant cloud propre au client, qui met à disposition les tables de vente structurées data (les tables de ventes dans Fabric ou Snowflake, les budgets, les marts de KPI) ainsi que les référentiels non structurés (contrats, politiques, présentations destinées au conseil d’administration et procédures dans SharePoint ou Drive) via un point d’accès unique et contrôlé. À cela s’ajoute une couche de connaissances métier : le glossaire officiel, les définitions des indicateurs clés de performance (KPI) telles que rédigées par le service financier, les règles métier (“ un trimestre se termine le 25 ”, “ exclure les transactions intra-groupe du chiffre d’affaires net ”), ainsi qu’une description sémantique de chaque document afin que le modèle puisse trouver le bon fichier et le lire dans son intégralité plutôt que de deviner à partir d’un extrait. L’accès reflète les autorisations existantes de chaque collaborateur ; ainsi, le modèle ne vous montre que ce que vous pouvez déjà ouvrir vous-même. Et chaque réponse comporte une référence : le tableau, le filtre de ligne, le document, la page. Je pense que c’est là que se joue le succès ou l’échec de l’IA d’entreprise, et c’est la partie que presque tout le monde néglige parce qu’elle ressemble à de la « plomberie ». Sans cela, le modèle reste un brillant inconnu. Avec cela, c’est un collègue qui a tout lu et qui peut le prouver.

Adopter. Formation, service par service, sur la société en production data. Je suis devenu allergique à ces “ masterclasses sur les techniques d’animation ” génériques, avec leurs exemples d’e-mails et leur entreprise fictive : elles suscitent une semaine de curiosité, puis le silence. Les sessions qui fonctionnent sont d’un tout autre genre. Le service commercial consacre deux heures et demie à une seule question concrète concernant le dernier trimestre. Le service financier procède au rapprochement d’un véritable dossier de fin de mois. Les RH reconstituent un véritable rapport d’absentéisme. Le service juridique examine un véritable accord de confidentialité à la lumière du guide de l’entreprise. Chaque participant repart avec un « projet Claude » qui reprend les règles de son service et un document concret qu’il rouvrira dès lundi. La différence ne réside pas dans la pédagogie. Elle tient au fait de savoir si le modèle avait été validé avant que quiconque ne soit formé à son utilisation.

Construire. Des agents de production, développés au cours de sprints courts par des ingénieurs travaillant aux côtés de l’équipe du client, sur un framework géré par ce dernier. C’est dans ce travail peu prestigieux — l’importation des factures des fournisseurs dans un schéma et le signalement des lignes non correspondantes, la rédaction des comptes-rendus de réunion et des actions à mener à partir d’une transcription de Teams, la vérification d’un accord de confidentialité au regard des directives internes et la synthèse des clauses de responsabilité et de résiliation, l’extraction des chiffres d’une pile de PDF pour les intégrer dans le modèle de souscription — que l’on passe le plus de temps, et c'est là que la plupart des programmes d'agents n'arrivent jamais, car ils commencent par quelque chose d'impressionnant plutôt que par quelque chose d'utile.

Ces quatre éléments constituent un système, et non un menu, et j'irais même plus loin : Se contenter de l'une de ces mesures sans les autres est souvent pire que de ne rien faire. Une formation sans mise en pratique donne l’impression aux utilisateurs que l’outil fonctionne de manière erronée, et ils ont raison. Une mise en pratique sans formation revient à construire une cathédrale dans laquelle personne n’entre. Des agents dépourvus de plateforme génèrent une douzaine d’automatisations disparates, sans gouvernance commune, et l’équipe de sécurité finit par les désactiver, à juste titre.

Le calcul auquel je reviens sans cesse est simple :

Valeur = Modèle × Couche de déploiement.

Ce nombre est extrêmement grand. Si vous le multipliez par zéro, vous obtenez zéro. Chaque nouvelle version issue des laboratoires renforce le premier facteur et rend le second plus déterminant.

Et voici le point délicat pour tous ceux qui espèrent s’en sortir en mettant le prix : la couche de déploiement ne peut pas être achetée sous forme de logiciel. Les laboratoires vendent le modèle et la plateforme, et ils ont raison de s’en tenir là. Le contexte, les autorisations, les habitudes au niveau des services et les premiers agents sont propres au modèle « data » et à la culture de chaque entreprise — quel système constitue la source de vérité pour un client, qui est autorisé à consulter la marge par produit, comment l’équipe financière clôture réellement le mois. Ils doivent être installés dans le bâtiment, par des personnes qui maîtrisent à la fois la feuille de route du modèle et les systèmes du client. Il n’y a pas de raccourci, et je me méfie de quiconque en propose un.

Exemple — Qui répond à la question relative aux ventes ?

Prenons une question simple qu’un directeur commercial pourrait poser un lundi matin : “ Quels ont été les résultats de Skala au dernier trimestre par rapport à la même période de l’année précédente, et où avons-nous perdu des parts de marché ? ”

Au Bora Brasil, au sein du groupe de soins capillaires issu de la fusion entre Skala Brasil et Lola From Rio, cette question avait l’habitude de faire le tour. Du directeur à un analyste, de l’analyste à un extrait de BI, de l’extrait à une feuille de calcul, de la feuille de calcul à une présentation, puis de retour au directeur trois jours plus tard, moment où la question de suivi avait déjà changé. Pendant ce temps, quinze pionniers utilisaient déjà Claude de manière informelle, en le connectant à leur messagerie, à leur agenda, à Teams et à leurs fichiers, obtenant ainsi des réponses plausibles dont personne ne pouvait retracer la source et qui utilisaient parfois une définition du terme “ partager ” que personne au service financier ne reconnaissait.

Les trois conditions requises pour exercer un leadership correspondaient exactement aux trois questions ci-dessus : des réponses fondées sur le modèle data propre au groupe, un accès respectant les autorisations existantes et un environnement réglementé afin que les informations commerciales sensibles cessent d'être transférées vers des outils non autorisés. C'est ce qu'on appelle le « moment 14% », vu de l'intérieur.

Ce qui a changé au cours de ces neuf semaines, ce n'est pas le modèle. Trois axes ont évolué en parallèle : un axe d'adoption « de la base vers le sommet », un axe de feuille de route « du sommet vers la base » et un axe de gouvernance.

  • Les travaux d'ingénierie réalisés une plateforme contextuelle sur Azure, approuvée par la direction technique du groupe, qui met à disposition Microsoft Fabric (ventes, indicateurs clés de performance, budgets) et SharePoint (contrats, politiques, présentations) via un seul serveur MCP.
  • Une couche de connaissances métier contient le glossaire, les définitions des indicateurs clés de performance (KPI) et les règles métier, ainsi qu'une description sémantique de chaque document, ce qui permet à Claude de localiser et de lire le fichier dans son intégralité.
  • Access reprend les autorisations existantes de chaque salarié, et Chaque figure mentionne la table ou le document dont elle est tirée.

Parallèlement, les entretiens menés avec les responsables des départements Commercial, Marketing, Innovation et R&D, Opérations, Finance et Ressources humaines ont permis d’identifier 83 opportunités, notées en fonction de leur valeur commerciale et de leur complexité technique ; ce nombre a été ramené à 24, puis, lors d’un atelier destiné aux dirigeants, à cinq pour la feuille de route de la première année.

C’est alors — et alors seulement — qu’a eu lieu la formation, consacrée précisément à cette question relative aux ventes. Au cours d’une session de 150 minutes, chaque participant a configuré un projet Claude avec les règles métier, extrait les définitions des indicateurs clés de performance (KPI) depuis SharePoint, planifié la requête avant de l’exécuter sur Fabric, créé un tableau de bord commercial interactif pouvant être partagé et vérifié la source de chaque chiffre. Les plus rapides ont intégré ce tableau de bord à leur routine hebdomadaire dans Cowork avant même la fin de la session. Le guide de l’animateur, lui-même créé avec Claude, a suivi pas à pas les progrès de chaque participant.

Soixante-deux collaborateurs sont actuellement en service, et ce chiffre devrait passer à 150, avec des licences attribuées en fonction des rôles et des domaines, un bureau dédié à l'IA au cœur de l'organisation et un référent dans chaque secteur d'activité. Les trente premiers titulaires de licence rendent compte au moins quatre heures gagnées par semaine en moyenne; sept personnes sur dix gagnent trois heures ou plus. Une conversion de la charge de travail liée à la paie RH (data) cela a pris 90 minutes au lieu des 40 heures de consultation prévues initialement par un prestataire externe. Un rapport de suivi du temps de travail qui nécessitait auparavant huit heures de vérification manuelle est désormais généré de manière automatisée selon un calendrier défini.

Je vous raconte cette histoire non pas parce que les chiffres sont élevés — il s'agit de chiffres préliminaires et fournis par les intéressés eux-mêmes —, mais parce que c'est la séquence qui constitue la leçon. Commencez par la mise à la terre. Entraînez-vous sur l'élément mis à la terre. Transmettez cette habitude à quelqu'un qui reste sur place. Inversez l'ordre et vous obtenez un webinaire.

Le modèle opérationnel de déploiement avancé

Si la couche de déploiement est mise en place par des personnes plutôt que d’être achetée sous forme de produit, la question qui se pose alors est de savoir quelles personnes et selon quelle organisation. 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 qu'un livrable. Trois verbes le décrivent.

Intégrer

Associez un un stratège en mission sur le terrain aux côtés d'un ingénieur en mission sur le terrain et de les intégrer tous deux au sein même du client, physiquement si possible, pendant toute la durée du projet. Le stratège est responsable des résultats commerciaux et du modèle opérationnel : quels processus, quels services prioritaires, lesquels des 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 est responsable de la plateforme, de la couche contextuelle et des agents : le serveur MCP et ses connecteurs, le modèle d’autorisation, le cadre des agents, ainsi que l’intégration avec les systèmes déjà en place chez le client. Au cours d’une semaine type, le stratège se trouve le matin dans le bureau du directeur financier et l’ingénieur travaille en binôme avec l’équipe data du client l’après-midi ; tous deux participent à 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 un 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é.

  • 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.
  • 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.
  • Et, pour les équipes d'ingénieurs, mise en œuvre sur Claude Code et Codex — des hackathons, des permanences, un volet de gouvernance consacré à l'accès et aux coûts — mesurés 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 arrivent par bateau sprints de deux semaines. La première journée consiste en un atelier pratique intitulé “ Comment créer un agent ” 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 un cadre 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 en lui fournissant le schéma et les documents de référence, ce qui génère un dossier structuré destiné à être examiné par un humain — ainsi que des modèles de prompt, de courtes vidéos, un responsable métier désigné, un utilisateur test et un responsable de la maintenance qui a suivi de près la mise en place du système.

Le succès ne se mesure pas au nombre de quatre agents que nous expédions. C'est le vingtième que le client réalise ensuite sans nous. Si ce nombre 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 licences et fait l'impasse sur la couche de déploiement. Le nombre de licences est passé à trois mille ; le taux d'utilisateurs actifs n'a pas évolué. Les collaborateurs 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 trouvent désormais dans des historiques de discussion que personne ne contrôle et que personne ne peut supprimer. Trois services ont chacun acheté 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 contrôle 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 décide donc d'affecter ses ingénieurs solutions, dont les ressources sont limitées, à un autre client. L'organisation a réglé les frais liés à la frontière et a reçu 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 n'est dû à une défaillance de la technologie, et très peu de ces problèmes sont imputables aux employés. C'est la conséquence prévisible du fait de considérer une compétence comme un simple achat, et du fait que personne n'assume la responsabilité de l'écart qui existe entre le fait de détenir une licence et celui d'en avoir pris l'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 en première ligne 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 en Europe, au Moyen-Orient et en 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 — se concentrer sur la stratégie commerciale et laisser à d'autres le soin de s'occuper des aspects techniques — est précisément ce qui a conduit le secteur à la situation 14%.

Ce pari repose sur quelques convictions auxquelles je tiens fermement :

  • Cela L'ancrage passe avant l'entraînement, en toutes circonstances, et qu’une séance de formation qui ne fait pas appel au data propre au client n’est qu’une mise en scène.
  • Cela un agent dont le propriétaire n'est pas désigné et un gestionnaire constitue un fardeau, et non un atout, aussi compétent soit-il.
  • Que le L'équipe du client doit faire mieux 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 quelque 1,2 milliard de livres sterling d'actifs sous gestion, constitue pour moi la preuve la plus évidente que la troisième thèse est fondée. Un atelier organisé au printemps avait mis en lumière les contraintes habituelles des services administratifs : une centaine de factures fournisseurs par mois ressaisies à la main, une heure et demie pour valider les comptes rendus de chaque grande réunion, des examens des accords de confidentialité 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.

Dans un sprint de deux semaines Au sein de leur environnement Microsoft, une équipe interfonctionnelle a mis en place quatre Agents utilisant Claude pour remédier précisément à ces quatre problèmes :

  • comptes fournisseurs (80% de temps économisé par facture, plus de 90% de lignes de facture mises en correspondance automatiquement),
  • Examen de la NDA (de trois jours à moins de deux heures),
  • initialisation de la souscription (de 25 heures à moins de trois)
  • , d' compte rendu de réunion (entre une heure et demie et 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 ”, a déclaré Phil Price, leur responsable FP&A, ajoutant : “ Elle nous a mis dans de bonnes conditions pour continuer à nous développer et à nous étendre par nos propres moyens. ” La première partie de cette phrase est flatteuse. C'est la seconde mi-temps qui compte.

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 —, cela signifie que vous ne disposez pas encore de capacités en matière 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