Prendre RDV →
Déployer l’IA en entreprise.
Un métier humain.
La méthode Kokoro de déploiement de l’IA en PME et ETI, tirée de plus de cinquante accompagnements.
Les équipes d’abord.
Depuis près de deux ans, j’ai accompagné plus de cinquante PME et ETI dans leur déploiement de l’IA. J’ai appris une chose simple : l’IA n’échoue presque jamais pour des raisons techniques. Elle échoue parce qu’on a oublié les gens.
Le scénario se répète. Une direction motivée, des abonnements achetés, deux ou trois enthousiastes qui s’y mettent. Et puis rien ne se diffuse. Six mois plus tard, l’IA est dans l’entreprise sans avoir rien changé à la façon de travailler.
Ce playbook met les équipes, les métiers et la conduite du changement au centre. L’outil reste à sa place : un moyen, jamais une fin.
Une organisation ne se transforme pas parce qu’elle a installé l’IA. Elle se transforme quand ses équipes s’en emparent.
C’est un travail collectif, pas une décision qui descend d’en haut. À chaque étape, l’enjeu est le même : recréer du collectif autour du sujet. C’est ce qui sépare un déploiement qui tient d’un outil de plus que personne n’ouvre.
Quatre étapes qui reviennent dans chaque mission.
La plupart des dirigeants se croient plus avancés qu’ils ne le sont. Situer honnêtement son entreprise sur ce chemin est souvent le premier vrai pas.
Gouvernance
De l’usage sauvage au cap partagé : qui décide, charte, kickoff porté par la direction.
Acculturation et cas d’usage
Démystifier, former, faire émerger les usages qui comptent avec les équipes.
Production
Construire et déployer pour de vrai, équipe par équipe, builders et champions.
Ancrage et autonomie
Mesurer l’impact, ancrer les usages, rendre l’entreprise autonome.
Quatre phases, une par étape. Chacune suit le même fil : l’objectif, la méthode pas à pas, les erreurs à éviter, un ou deux cas réels rendus anonymes, et les ressources prêtes à l’emploi. Tout vient de nos missions. Les chiffres sont ceux que j’ai mesurés sur le terrain.
On regarde ensemble où en est votre organisation et par quelle phase commencer.
Gouvernance
poser le cap.
De l’usage sauvage au cap partagé. Cette phase ne produit presque rien de visible : c’est pourtant elle qui décide si tout le reste tiendra.
L’objectif de la phase
Avant cette phase, l’IA circule dans l’entreprise sans cap ni règles. Chacun bricole de son côté, personne ne décide. La Phase 1 ne produit presque rien de visible, et c’est ce qui la rend si facile à négliger. Pourtant, c’est elle qui décide si tout le reste tiendra.
Avant de toucher au moindre outil, une question doit trouver sa réponse, et presque personne ne se la pose : qui, dans l’entreprise, a le droit de décider sur l’IA, et au nom de quoi ? C’est la mission de la gouvernance : donner un cap et un cadre de décision. C’est ce qui fait passer l’IA d’une collection d’initiatives individuelles à un projet que l’entreprise porte ensemble.
- 01une intention claire, formulable en une phrase ;
- 02une gouvernance posée : qui décide, qui pilote, qui construit, avec un responsable IA nommé ;
- 03une charte IA qui fixe les engagements et les limites ;
- 04un kickoff qui a officialisé le sujet auprès des équipes.
Aucun agent n’a encore été construit. Mais l’entreprise sait désormais pourquoi elle s’y met, et qui mène.
Le fil est simple : amener une direction qui veut faire de l’IA à une direction qui sait qui décide, pour quoi, et qui l’a dit à ses équipes. Cinq étapes, dans l’ordre.
Comprendre l’organisation
Je commence toujours par lire l’entreprise. Pas ses outils, son fonctionnement humain. C’est ce diagnostic qui rend tout le reste possible.
1.1 Lire le management. La place du dirigeant, comment les décisions circulent, l’entreprise est-elle plutôt verticale ou horizontale. En vertical, un projet porté d’en haut avance vite mais n’embarque que si l’ordre est clair. En horizontal, il faut convaincre plus de monde, mais l’adhésion est plus solide.
1.2 Repérer les appuis et les freins. Le frein vient rarement du dirigeant, plus souvent de la DSI, du juridique, parfois du DRH inquiet pour ses équipes. Ce ne sont pas des adversaires : chacun voit les risques de son périmètre. Je les repère tôt pour avancer avec eux.
1.3 Vérifier la standardisation. Une entreprise qui veut de l’IA mais n’a jamais standardisé ses process : on ne peut pas demander à une machine d’automatiser un terrain mouvant. Ce qui est standardisable doit l’être d’abord.
Définir les objectifs avec la direction
L’objectif revient toujours à trois choses : gagner du temps, gagner de l’argent, ou réduire la pénibilité. Mais l’ordre de priorité change tout, et toute la feuille de route en découle.
Je ne juge jamais la vision du dirigeant, je construis l’exécution en face. L’un veut réduire sa masse salariale, l’autre met le bien-être de ses équipes au centre. Ce ne sont pas mes valeurs qui priorisent les projets, ce sont les siennes.
Poser la gouvernance
L’intention claire, je structure la décision. Une gouvernance claire tient sur trois rôles, et les confondre coûte cher.
Décide, arbitre et valide. Une seule personne nommée décideur.
Organise le suivi et les évolutions dans la durée.
Construit les systèmes, forme les équipes et fait tourner.
Cadrer le comité IA. Quand on élargit le cercle, le comité communique et embarque, il ne décide pas : la décision reste à la direction et au leadership IA. Poser ce cadre dès le départ évite la dérive la plus fréquente de cette phase.
On aligne d’abord la direction, ensuite le leadership IA, et seulement après on élargit. Sauter une marche, c’est ouvrir le débat avant d’avoir un cap, et le débat sans cap ne se referme jamais.
Rédiger la charte IA
On formalise dans le seul document de la phase : la charte. C’est un outil de communication avant tout. Le fond est stable : ce que la direction s’engage à faire avec l’IA, ce qu’elle ne fera pas, qui gouverne, et quelques lignes d’éthique. Elle devient la référence commune.
Lancer le kickoff
Tout ce qui précède ne vaut que si la direction le dit elle-même. Le dirigeant porte le message en personne : ce sujet compte, et chacun est attendu. C’est ce moment qui fait basculer l’IA du statut de rumeur à celui de projet officiel.
Faute de cadre, il discute pendant des mois, dérive sur la RH, et personne ne tranche.
Quand personne n’est responsable d’une décision, personne ne la prend.
Si le dirigeant ne porte pas le sujet, aucune gouvernance ne compensera.
Choisir une solution avant d’avoir posé le cap, c’est une techno que personne ne s’approprie.
Plusieurs entreprises où il était impossible d’avancer : tout le monde voulait s’y mettre, mais personne n’avait le droit de choisir une solution. Tant qu’un nom n’est pas posé en face de la décision, je ne lance rien. Le décideur nommé n’est pas une formalité, c’est ce qui débloque le reste.
Une ETI de services de près de quatre mille personnes, reprise par le fils du fondateur, qui a fait du projet IA le cœur de l’évolution. Chaque manager était responsable, et incentivé, sur la transformation de son équipe. Les plus anciens étaient parmi les plus investis. Tout a tenu parce que le cap descendait jusqu’au dernier manager. Une transmission bien portée, c’est un moteur.
C’est fait quand
On ne passe pas à la suite tant qu’il reste un non.
- ✓La direction sait-elle dire, en une phrase, pourquoi elle se lance ?
- ✓Une personne est-elle clairement nommée comme responsable IA ?
- ✓Le comité IA sait-il qu’il communique et n’arbitre pas ?
- ✓Le dirigeant a-t-il dit aux équipes, avec ses mots, que le sujet compte ?
- ✓Ai-je identifié qui freine dans la direction, et pourquoi ?
Acculturation
et cas d’usage.
La gouvernance a posé le cap. Reste le plus délicat : transformer les irritants du terrain en cas d’usage que les équipes adoptent, et en un plan que la direction peut tenir.
L’objectif de la phase
La mission de cette phase est de faire émerger, avec les équipes, les usages qui comptent, puis de les transformer en un plan priorisé et défendable. Un principe la tient d’un bout à l’autre : les meilleurs cas d’usage ne se décrètent pas en réunion de direction, ils remontent du terrain. Mon rôle est de créer les conditions de cette remontée, puis de mettre de l’ordre dans ce qui remonte.
Deux attentes se rencontrent ici. Pour le dirigeant : sortir de la liste de bonnes intentions et obtenir un plan lisible. Pour les équipes : passer de spectatrices à actrices, et reconnaître leur propre métier dans ce qu’on va construire.
- 01un diagnostic du terrain (process, irritants, pistes), quand on est entré par l’audit ;
- 02un catalogue de cas d’usage cadrés ;
- 03une feuille de route IA priorisée, son tableau de bord et sa présentation pour la direction.
Le fil : partir des gens et de leurs irritants, finir avec un plan que la direction peut tenir. Sept étapes, dans l’ordre.
Choisir la porte d’entrée
Il y a deux façons d’entrer dans cette phase, et les deux marchent. Le choix dépend de l’entreprise.
On réunit les équipes et on fait émerger les usages ensemble, par un hackathon ou une formation par métier. On entre par l’énergie.
On entre par un audit, des entretiens et une cartographie, pour comprendre chacun en profondeur avant de construire.
Un peu d’audit pour cartographier, un hackathon pour embarquer. L’entreprise qui se confie en tête à tête se prête à l’audit ; celle qui ne s’ouvre qu’entre collègues donne plus en collectif.
Créer un langage commun : l’acculturation
Avant de faire émerger quoi que ce soit, je mets tout le monde au même niveau. Une acculturation courte, de deux heures à une journée selon la maturité. L’objectif n’est pas de former des experts, c’est de démystifier l’IA et de donner un langage commun, pour que les gens osent proposer. Sans ce préalable, seuls les plus à l’aise parlent, et on passe à côté des autres.
Faire remonter les usages du terrain
C’est le cœur de la phase. Dans les deux cas, je cherche la même chose : l’irritant réel et le gain potentiel, en temps, en argent ou en pénibilité.
3.1 Par le hackathon ou la formation par métier. Une masterclass pour montrer comment se construit un agent, puis chaque équipe construit les siens sur ses propres problèmes, avec des formateurs qui circulent. La sortie n’est pas un livrable fini, c’est que chacun reparte en sachant construire. Et pour moi, c’est le meilleur outil de remontée : je vois ce qui marche, ce qui bloque, et l’effort réel que demande chaque idée.
3.2 Par l’audit. Des entretiens en tête à tête, l’analyse des systèmes et de la qualité des données, puis des ateliers. L’outil clé : la journée du collaborateur, qu’on décrit pas à pas pour en extraire les irritants. On cartographie les process qui comptent, pas tous.
Cadrer chaque cas d’usage
Avant de choisir le moindre outil, je cadre le périmètre. Trois questions, toujours les mêmes. Tant que ce pipeline n’est pas clair, on ne choisit rien.
Choisir la nature de la solution
Un cas cadré se range dans une des trois catégories. Ce ne sont pas des niveaux de qualité, mais des natures différentes.
Pour une demande simple et ponctuelle.
Quand ça doit se déclencher tout seul, sur un cas prédictif où il faut toujours le même résultat.
Quand il peut y avoir des exceptions, du non-prédictif, et qu’on veut qu’il décide.
Mon parti-pris : viser l’agent le plus simple possible, jamais le plus impressionnant. Un bon prompt bien intégré crée souvent plus de valeur qu’un agent que personne n’ose lancer.
5.1 Pour un agent, fixer le degré d’autonomie. Quatre degrés, du plus prudent au plus libre. Ce choix n’est pas technique, il est humain : plus le degré monte, plus l’enjeu de confiance monte. Dans une entreprise à forte culture, on commence bas.
- 01Il lit et conseille, sans rien engager.
- 02Il propose et attend une validation à chaque action.
- 03Il exécute des actions préapprouvées, sous surveillance.
- 04Il agit seul, l’humain ne fait que superviser.
Prioriser
Toutes les idées ne se valent pas. Je les score avec une matrice ICE : l’impact, la confiance dans la faisabilité, la facilité de mise en œuvre. Ce score est mon travail, pas celui des équipes : ni un vote, ni un calcul automatique, mais une lecture du terrain croisée entre les profils. Sa force tient à une règle : il ne se remplit jamais sur du déclaratif, mais sur ce que le hackathon ou l’audit ont réellement montré.
Souvent, le cas au plus fort impact n’est pas celui qu’on lance en premier : quand la donnée n’est pas accessible ou que le process n’est pas standardisé, on prépare le terrain avant.
Produire la feuille de route IA
Tout se consolide dans un seul livrable : la feuille de route. Un tableau qui suit chaque cas d’usage, de l’irritant d’origine jusqu’à sa vague de déploiement, et une présentation pour la direction. Chaque ligne relie un problème de terrain à une solution, un degré d’autonomie, une priorité et un gain attendu. C’est le document qui fait passer l’entreprise de l’intention au plan, et qui donne au dirigeant un objet qu’il peut réellement piloter.
Parler uniquement process, outils et données déshumanise la démarche et fait décrocher les équipes. Ces moments embarquent d’abord des gens.
Ce qu’un collaborateur imagine comme solution n’est pas toujours la source de son irritant. On creuse jusqu’à la cause avant de construire.
On repart avec un irritant mais incapable de construire derrière, faute d’avoir compris le process en détail.
L’agent utile et adopté vaut mieux que celui qui impressionne en démo. Le perfectionnisme retarde la mise en service et démobilise.
Les bons cas d’usage viennent de ceux qui font le travail. Imposés depuis une réunion de direction, ils tombent à plat.
Dans une ETI où une trentaine de personnes étaient mobilisées, on a tenu un hackathon. La plupart utilisaient l’IA de façon très basique, un chat de temps en temps. En un à deux jours, par équipes, ils ont construit une dizaine d’agents sur leurs propres irritants. Ce qui a changé, ce n’est pas les agents, c’est qu’ils ont compris qu’ils pouvaient construire. À partir de là, les idées ont continué à remonter toutes seules.
Plusieurs fois, le cas le plus prometteur sur le papier butait sur une donnée qu’on ne pouvait pas récupérer, ou sur un process que chacun faisait à sa façon. Avant de mettre de l’IA, il a fallu standardiser. J’ai appris à le voir tôt : un cas séduisant posé sur une base instable coûte plus cher qu’il ne rapporte.
C’est fait quand
- ✓Les irritants sont-ils remontés du terrain, pas devinés en réunion ?
- ✓Chaque cas retenu est-il cadré : quelle donnée entre, ce qu’on en fait, ce qui sort ?
- ✓La priorisation s’appuie-t-elle sur du concret produit, pas sur du déclaratif ?
- ✓La feuille de route relie-t-elle chaque cas à un irritant, une priorité et un gain ?
- ✓La direction a-t-elle validé le plan et son séquencement ?
Production
construire ensemble.
On sait quoi construire. Reste à le faire avec les équipes, et à déployer service par service jusqu’à ce que les outils servent vraiment.
L’objectif de la phase
La mission de cette phase est de transformer la feuille de route en systèmes qui tournent et que les équipes utilisent. Pas une démo qui impressionne, pas un prototype qui dort dans un dossier : des agents en service, adoptés par ceux dont ils étaient censés alléger le travail.
Un principe la tient d’un bout à l’autre : on ne construit jamais pour les équipes, on construit avec elles. La technique est la partie facile. Le vrai travail est de garder, à chaque étape, la personne du métier dans la boucle, parce que c’est elle qui décidera de l’utiliser ou de l’abandonner.
- 01une organisation de production : des builders, une équipe de champions, et le binôme qui les relie ;
- 02un socle et une stack techniques choisis et posés ;
- 03une feuille de production qui ordonne les cas d’usage en vagues ;
- 04les premiers agents construits, validés et déployés par batch ;
- 05une équipe reformée sur les outils qu’elle vient de recevoir.
Le fil : partir de la feuille de route priorisée, construire au plus près des métiers, et déployer service par service. Sept étapes, dans l’ordre.
Monter l’équipe de production
Avant de construire quoi que ce soit, je pose qui construit. Une production qui tient repose sur deux profils et le lien entre eux.
Il met les mains dans le système : prompts, workflows, agents. Il traduit un besoin en système qui marche.
Pas un profil tech, et c’est volontaire. Il exprime le besoin, teste, valide. Un expert de son propre métier.
Jamais un pour un : un builder pour plusieurs champions. C’est ce qui rend la production tenable, sans armée de techniciens.
Choisir et poser le socle et la stack
Je fixe les fondations avant le premier agent, parce qu’en changer après coûte cher. Le socle se choisit selon l’entreprise : sa réalité de données, ses contraintes, son budget, sa sensibilité. On choisit l’outillage qui sert les cas d’usage prioritaires, pas l’inverse.
Établir la feuille de production
La feuille de route disait quoi construire et dans quel ordre. La feuille de production traduit cette priorité en travail concret : quel cas part en premier, qui le porte, quel champion lui est associé, dans quelle vague il tombe. C’est le plan de marche des builders.
Construire en boucle ping-pong
Le cœur de la production. Chaque agent se construit dans un aller-retour serré entre le builder et son champion, jamais d’un seul jet.
4.2 Animer l’échange au quotidien. J’anime la boucle sur un canal dédié, un Slack ou un Teams, pour régler les correctifs au fil de l’eau.
4.3 Tracker les évolutions. Toutes les demandes se consignent dans une base (Notion, Sheet, Excel) : ça donne une mémoire à la production et ça nourrit les vagues d’après.
Valider la qualité de l’agent
Un agent ne sort de la boucle que quand le champion confirme qu’il répond à son besoin, sur ses vrais cas, pas en démo. C’est lui le juge, parce que c’est lui qui devra s’en servir tous les jours. Cette validation par l’usage réel, et non par une recette technique, sépare un système adopté d’un prototype abandonné.
Déployer par batch
Les agents validés, je les déploie service par service. Je regroupe par service parce que c’est là qu’on maximise le rendement : mêmes process, mêmes données, mêmes irritants, et un agent qui marche pour l’un marche souvent pour ses voisins.
Reformer l’équipe sur les outils livrés
Un agent déployé n’est pas un agent adopté. À chaque batch, je reforme l’équipe qui le reçoit sur l’outil qu’elle vient d’avoir entre les mains, sur ses cas à elle. Sans ce passage, l’outil reste à côté du travail au lieu d’entrer dedans. C’est la dernière marche avant le run.
Un agent monté par le builder seul répond à un problème imaginé, pas au vrai. Il finit dans un dossier que personne n’ouvre.
On cherche quelqu’un qui connaît le métier et sait dire son besoin, pas un second builder.
Coller un builder à un seul champion gâche la ressource rare. Un builder doit tenir plusieurs champions.
Valider de loin en loin laisse l’agent dériver loin du besoin. Le ping-pong doit être rapide et continu.
Poser la stack en cours de route oblige à tout refaire. On fixe les fondations avant le premier agent.
Lancer un service dont les process ne sont pas standardisés, c’est bâtir sur du sable.
Un agent livré sans reformation reste à côté du travail. La prise en main fait partie du déploiement.
Sur les productions qui ont le mieux tourné, je n’ai jamais collé un technicien derrière chaque équipe. Un builder accompagnait plusieurs champions, des gens pas du tout tech mais qui connaissaient leur métier sur le bout des doigts. Tout passait par un canal Slack dédié : le champion testait, remontait, le builder corrigeait dans la foulée. Ce n’est pas la technique qui faisait la différence, c’est ce dialogue rapide et le fait que le métier validait lui-même.
Quand je déploie par service, c’est pour maximiser le rendement. La vraie difficulté n’est presque jamais l’agent, c’est l’état des systèmes du service. Là où tout était clean et standardisé, le batch passait vite. Là où chacun faisait à sa façon, il fallait d’abord remettre de l’ordre.
C’est fait quand
On ne passe pas à la suite tant qu’il reste un non.
- ✓Chaque cas d’usage a-t-il un builder et un champion du métier identifiés ?
- ✓Les champions sont-ils des profils métier, pas des techniciens ?
- ✓Le socle et la stack ont-ils été posés avant de construire ?
- ✓La construction se fait-elle en aller-retour rapide, avec un canal dédié et une base qui trace ?
- ✓Chaque agent déployé a-t-il été validé par son champion, sur de vrais cas ?
- ✓Les services visés ont-ils des process assez au propre pour recevoir leur batch ?
- ✓Chaque équipe a-t-elle été reformée sur l’outil qu’elle vient de recevoir ?
Cette phase produit les premiers systèmes qui tournent en vrai. Chaque livrable vient avec la ressource Kokoro qui sert à le produire.
Ancrage
rendre autonome.
Un usage qui marche pendant qu’on est là ne prouve rien. Cette phase a un seul enjeu : faire en sorte que tout tienne sans nous. C’est la phase où l’on prépare son propre départ.
L’objectif de la phase
La mission de cette phase est de transformer des usages qui fonctionnent en une capacité qui dure : ancrer l’IA dans les habitudes, mesurer ce qu’elle produit vraiment, aller chercher ceux qui résistent encore, et rendre l’entreprise capable de continuer seule. La vraie réussite ne se mesure pas le jour de la mise en service, mais des mois plus tard, quand l’équipe n’a plus besoin de nous.
- 01une charte qui tient et sert de référence commune ;
- 02un niveau de maîtrise à peu près homogène en interne, pas concentré dans deux têtes ;
- 03une équipe support capable de porter les évolutions de l’IA seule ;
- 04une feuille de route claire que l’entreprise sait réévaluer elle-même.
Tant que ces quatre conditions ne sont pas réunies, le déploiement n’est pas terminé, même si les agents tournent.
Le fil : passer d’usages qui marchent quand on est là à une entreprise qui continue sans nous. Six étapes, dans l’ordre.
Mener la conduite du changement en profondeur
1.1 Devenir l’allié de chaque personne. Je deviens l’allié de chacun : je montre que je comprends son métier, ses contraintes, ce qui l’agace. Les gens n’adoptent pas une technologie, ils adoptent quelqu’un qui les a compris.
1.2 Faire entrer l’IA par les gestes déjà en place. On ne plaque pas un outil par-dessus une organisation, on le fait entrer par les habitudes qui existent déjà. Dans une entreprise à forte culture, on prolonge le déjà-là.
Reformer en T2, ciblé par métier
La Phase 2 a donné une formation généraliste. Ici, on monte d’un cran, mais ciblé : une formation par métier, sur les usages réels de chaque équipe. C’est ce passage qui homogénéise la maîtrise et évite que le savoir reste coincé chez les champions.
Outiller l’autonomie quotidienne
Une équipe autonome a besoin de points d’appui. Le principal, c’est la banque de prompts : un référentiel des prompts qui marchent, rangés par métier, que n’importe qui peut reprendre sans tout réinventer. Elle transforme le savoir de quelques-uns en ressource commune, disponible tout le temps, et permet aux profils les plus standards d’utiliser ce qui a été produit.
Mesurer l’impact
On ne peut ancrer durablement que ce qu’on sait mesurer. Les outils remontent de plus en plus de données d’usage : on voit qui utilise quoi, à quelle fréquence, sur quels cas.
4.1 Relier l’usage au gain. Mesurer, ce n’est pas compter les connexions, c’est rattacher chaque usage à un gain réel, en temps, en argent ou en pénibilité évitée.
4.2 En faire un levier d’adoption. Quand une équipe voit le temps qu’une autre a récupéré, elle veut la même chose. La mesure ne sert pas qu’à reporter, elle sert à embarquer.
Aller chercher ceux qui résistent encore
Il reste presque toujours des réticents. Et il faut voir qui ils sont : pas des profils techniques qui contesteraient un choix d’outil, mais des réticents au changement, tout court. On ne les retourne pas avec un argument technique.
5.1 Allier l’humain et la preuve. On retourne un réticent en mêlant deux choses. D’abord l’humain, en devenant son allié, par empathie réelle. Ensuite la preuve, par des cas d’usage qui marchent, conçus parce qu’on a compris son problème. L’humain seul ne suffit pas, la preuve seule non plus. C’est les deux ensemble qui font basculer.
Passer le relais et choisir la posture de sortie
Le déploiement se termine par une décision, et elle appartient au client. Deux postures, toutes deux légitimes.
On transmet la charte, on forme l’équipe support, on laisse une feuille de route qu’ils pilotent seuls, et on s’efface.
Le client préfère nous déléguer le travail dans la durée, garder un appui pour porter les évolutions.
Des agents qui tournent pendant qu’on est là ne prouvent rien. L’adoption se vérifie quand on n’y est plus, des mois après.
Si la maîtrise reste chez les champions, l’entreprise dépend d’un point de fragilité. La T2 et la banque de prompts existent pour répartir ce savoir.
Leur sortir des arguments de données ne les retourne jamais. Sans l’humain, la preuve ne passe pas.
Le mépris pour celui qui n’adhère pas encore tue l’adoption. On devient son allié, on ne le contourne pas.
Un gain qu’on ne montre pas est un gain qui n’embarque personne, et qu’on ne peut pas défendre.
Notre réussite, c’est que ça tienne sans nous. Un accompagnement qui se rend indispensable a raté sa Phase 4.
Dans des entreprises où les équipes commerciales produisaient beaucoup de slides, on a standardisé les présentations dans l’outil et accompagné les équipes pour les produire avec. Selon la complexité, le gain allait d’une heure à une journée de travail entière, par présentation. La leçon : on cherche souvent l’agent sophistiqué, alors qu’un seul cas banal, bien standardisé et vraiment adopté, produit parfois le plus gros gain.
Sur plusieurs missions, les derniers à convaincre n’étaient pas des profils techniques. C’étaient des gens réticents au changement, point. Ce qui les a fait basculer, ce n’est jamais un argument technique. C’est d’être devenu leur allié d’abord, puis de poser devant eux un cas d’usage qui marchait, conçu parce qu’on les avait écoutés. L’humain ouvre la porte, la preuve la franchit.
C’est fait quand
On ne passe pas à la suite tant qu’il reste un non.
- ✓L’usage tient-il sans nous, ou seulement parce qu’on est encore là ?
- ✓La maîtrise est-elle homogène en interne, et pas concentrée chez deux personnes ?
- ✓Une équipe support est-elle capable de porter les évolutions seule ?
- ✓L’entreprise a-t-elle une feuille de route claire qu’elle sait réévaluer elle-même ?
- ✓Mesure-t-on l’impact réel, en temps, en argent ou en pénibilité ?
- ✓Les derniers réticents ont-ils été abordés par l’humain autant que par la preuve ?
Cette phase ne produit pas de nouveaux agents, elle produit de l’autonomie.
Rendre les clés.
Au début de ce playbook, je décrivais le scénario que je rencontre le plus souvent : six mois après l’achat des outils, l’IA est dans l’entreprise sans avoir rien changé à la façon de travailler. Tout ce qui précède sert à écrire l’autre histoire, celle où, six mois plus tard, l’IA a changé des gestes, allégé des journées, et où l’équipe avance sans nous.
D’une phase à l’autre, ce qui a fait la différence n’a jamais été l’outil. C’était la gouvernance qui donne un cap, les équipes qu’on écoute avant de construire, les champions qu’on reconnaît, les réticents qu’on retourne un par un. À chaque étape, le même travail : recréer du collectif autour du sujet.
Une organisation ne se transforme pas parce qu’elle a installé l’IA. Elle se transforme quand ses équipes s’en emparent.
C’est pour cela que la dernière phase rend les clés. On ne vient pas pour rester. Le jour où je quitte une entreprise et que l’IA continue d’y vivre, de se corriger et d’évoluer sans moi, la mission est réussie. Après plus de cinquante de ces accompagnements, ce que j’en retiens tient en une phrase : on ne réussit pas un déploiement à la place d’une équipe, on la rend capable de le réussir elle-même.
On déploie l’IA
avec vous.
Quatre façons d’avancer, selon où vous en êtes. On entre par celle qui a du sens pour votre entreprise, et on vous mène jusqu’à l’autonomie.
Formation
Mettre vos équipes au niveau, par métier, sur leurs vrais cas. Le langage commun qui débloque tout.
Audit IA
Cartographier vos process et faire émerger, avec le terrain, les cas d’usage qui comptent vraiment.
Agents IA
Construire et déployer les agents avec vos équipes, service par service, jusqu’au run.
Direction IA externalisée
Piloter votre transformation dans la durée, jusqu’à ce qu’elle tienne sans nous.