Un POC d’intelligence artificielle qui fonctionne sur un produit ne se r\u00e9plique presque jamais tel quel sur les autres. La raison n’est pas la qualit\u00e9 du POC : c’est que l’usage de l’IA varie fortement selon les m\u00e9tiers, que chaque produit repose sur une stack diff\u00e9rente, et qu’un socle important de code existant change enti\u00e8rement l’\u00e9quation par rapport \u00e0 un projet neuf. Passer \u00e0 l’\u00e9chelle rel\u00e8ve moins du choix d’outil que de l’organisation : il faut des personnes capables de porter la m\u00e9thode d’un contexte technique \u00e0 un autre \u2014 des t\u00eates de pont<\/strong> entre les \u00e9quipes.<\/p>\n\n\n\n Le sc\u00e9nario revient avec une r\u00e9gularit\u00e9 frappante dans les grandes organisations techniques, multi-produits et multi-technologies.<\/p>\n\n\n\n Une \u00e9quipe teste l’IA sur un p\u00e9rim\u00e8tre bien choisi. Souvent la QA, avec de l’automatisation de tests de non-r\u00e9gression : le terrain est balis\u00e9, les gains sont mesurables, les gens sont volontaires. \u00c7a marche. Les chiffres sont bons. La direction technique valide.<\/p>\n\n\n\n Puis vient la question suivante : on le d\u00e9ploie o\u00f9 maintenant ?<\/p>\n\n\n\n Et l\u00e0, le transfert ne se fait pas. Le produit d’\u00e0 c\u00f4t\u00e9 ne tourne pas sur les m\u00eames technologies. L’\u00e9quipe voisine n’a pas le m\u00eame rapport \u00e0 l’outil. Les profils qui ont port\u00e9 le pilote sont pris ailleurs. Six mois plus tard, l’organisation a une belle r\u00e9ussite isol\u00e9e et aucune capacit\u00e9 de reproduction.<\/p>\n\n\n\n Ce n’est pas un \u00e9chec d’ex\u00e9cution. C’est une erreur de mod\u00e8le : on a trait\u00e9 comme un projet outillage ce qui est un probl\u00e8me de diffusion de comp\u00e9tence.<\/strong><\/p>\n\n\n\n Un d\u00e9veloppeur Java et un expert m\u00e9tier n’utilisent pas l’IA de la m\u00eame mani\u00e8re, et pas pour les m\u00eames t\u00e2ches. Le premier cherche de la vitesse sur du code qu’il ma\u00eetrise d\u00e9j\u00e0. Le second cherche \u00e0 structurer une connaissance qu’il est souvent seul \u00e0 d\u00e9tenir.<\/p>\n\n\n\n Cons\u00e9quence pratique : une strat\u00e9gie d’adoption uniforme, avec le m\u00eame outil et la m\u00eame formation pour tout le monde, produit des r\u00e9sultats tr\u00e8s in\u00e9gaux \u2014 et donne l’impression que l’IA \u00ab marche pour certains \u00bb alors que c’est le cadrage qui est trop large.<\/p>\n\n\n\n Int\u00e9grer l’IA dans une base de code accumul\u00e9e sur de nombreuses ann\u00e9es n’a presque rien \u00e0 voir avec un projet d\u00e9marr\u00e9 de z\u00e9ro. Sur un projet neuf, le code est lisible par l’outil, la documentation est fra\u00eeche, les conventions sont homog\u00e8nes. Sur un socle ancien, l’IA doit d’abord comprendre un contexte que personne n’a jamais \u00e9crit nulle part.<\/p>\n\n\n\n C’est le point que les retours d’exp\u00e9rience publics passent le plus souvent sous silence, parce que la majorit\u00e9 des d\u00e9monstrations sont faites sur du greenfield.<\/p>\n\n\n\n Deux produits de la m\u00eame entreprise peuvent reposer sur des stacks suffisamment diff\u00e9rentes pour qu’un outillage calibr\u00e9 sur l’un soit inutilisable sur l’autre. Le prompt, le contexte inject\u00e9, les points d’int\u00e9gration dans la cha\u00eene de build : tout est \u00e0 recalibrer.<\/p>\n\n\n\n La le\u00e7on op\u00e9rationnelle est contre-intuitive. Ce qui se r\u00e9plique, ce n’est pas la solution. C’est la m\u00e9thode qui a permis d’y arriver.<\/strong> Et une m\u00e9thode ne se transf\u00e8re pas par documentation : elle se transf\u00e8re par des personnes.<\/p>\n\n\n\n Dans une organisation qui fait \u00e0 la fois de la recherche et de l’int\u00e9gration, ce sont deux m\u00e9tiers. La R&D travaille sur le c\u0153ur de l’outil. L’int\u00e9gration travaille sur le d\u00e9ploiement chez le client, avec ses contraintes, son existant, ses utilisateurs.<\/p>\n\n\n\n Les personnes capables de porter l’IA c\u00f4t\u00e9 int\u00e9gration ne sont pas n\u00e9cessairement celles qui ont brill\u00e9 sur le POC R&D. Confondre les deux est une cause fr\u00e9quente de blocage au moment du passage \u00e0 l’\u00e9chelle.<\/p>\n\n\n\n Le rythme d’\u00e9volution des outils d’IA est aujourd’hui plus rapide que le cycle de d\u00e9cision d’une grande organisation d’ing\u00e9nierie. Avant, une nouvelle version majeure de langage arrivait tous les deux ou trois ans et laissait le temps de s’organiser. Ce n’est plus le cas.<\/p>\n\n\n\n Il ne s’agit pas d’acc\u00e9l\u00e9rer artificiellement la d\u00e9cision, mais d’accepter une contrainte : la m\u00e9thode doit survivre au changement d’outil.<\/strong> Si votre plan de d\u00e9ploiement est index\u00e9 sur un mod\u00e8le ou un fournisseur pr\u00e9cis, il sera p\u00e9rim\u00e9 avant d’\u00eatre g\u00e9n\u00e9ralis\u00e9.<\/p>\n\n\n\n Le terme vient des organisations qui ont d\u00e9j\u00e0 but\u00e9 sur ce mur, et il d\u00e9crit pr\u00e9cis\u00e9ment le bon r\u00f4le.<\/p>\n\n\n\n Une t\u00eate de pont, c’est une personne \u2014 ou un bin\u00f4me \u2014 qui a port\u00e9 un d\u00e9ploiement IA jusqu’au bout dans un contexte donn\u00e9, et qui va porter le suivant dans un contexte diff\u00e9rent. Son r\u00f4le n’est pas de produire l’outillage. C’est d’assurer l’interconnexion entre les d\u00e9ploiements<\/strong> : transposer ce qui est transposable, identifier ce qui ne l’est pas, et \u00e9viter que chaque \u00e9quipe recommence \u00e0 z\u00e9ro.<\/p>\n\n\n\n Ce profil combine trois choses qu’on trouve rarement r\u00e9unies :<\/p>\n\n\n\n C’est cette troisi\u00e8me condition qui fait \u00e9chouer la plupart des cellules IA centrales. Une \u00e9quipe transverse qui arrive avec des bonnes pratiques mais sans avoir mis les mains dans le produit n’obtient pas l’adh\u00e9sion. La t\u00eate de pont fonctionne parce qu’elle travaille dans<\/strong> l’\u00e9quipe, pas pour<\/strong> l’\u00e9quipe.<\/p>\n\n\n\n Une approche progressive, qui accepte de construire la comp\u00e9tence avant de g\u00e9n\u00e9raliser.<\/p>\n\n\n\n \u00c9tape 1 \u2014 Choisir le premier p\u00e9rim\u00e8tre pour ce qu’il enseigne, pas pour ce qu’il rapporte.<\/strong> Le meilleur premier chantier n’est pas celui qui a le meilleur ROI th\u00e9orique, mais celui qui ressemble le plus au reste de votre portefeuille. Un pilote r\u00e9ussi sur un produit atypique n’apprend rien de r\u00e9utilisable.<\/p>\n\n\n\n \u00c9tape 2 \u2014 Documenter la m\u00e9thode, pas seulement le r\u00e9sultat.<\/strong> Ce qu’il faut capturer : quels contextes ont d\u00fb \u00eatre fournis au mod\u00e8le, quelles t\u00e2ches ont \u00e9t\u00e9 \u00e9cart\u00e9es et pourquoi, o\u00f9 l’humain est rest\u00e9 d\u00e9cisionnaire, quels signaux ont indiqu\u00e9 que la sortie n’\u00e9tait pas fiable. C’est cette mati\u00e8re qui se transpose.<\/p>\n\n\n\n \u00c9tape 3 \u2014 Faire porter le deuxi\u00e8me d\u00e9ploiement par les m\u00eames personnes, sur un contexte volontairement diff\u00e9rent.<\/strong> C’est le test r\u00e9el de r\u00e9plicabilit\u00e9. S’il faut tout refaire, la m\u00e9thode n’\u00e9tait pas une m\u00e9thode.<\/p>\n\n\n\n \u00c9tape 4 \u2014 \u00c9largir par duplication de personnes, pas d’outils.<\/strong> Chaque d\u00e9ploiement r\u00e9ussi doit produire au moins une nouvelle personne capable de porter le suivant. C’est le seul m\u00e9canisme de mise \u00e0 l’\u00e9chelle qui tient dans une organisation h\u00e9t\u00e9rog\u00e8ne.<\/p>\n\n\n\n \u00c9tape 5 \u2014 Mesurer l’adoption, pas l’activit\u00e9.<\/strong> Le nombre de licences distribu\u00e9es ne dit rien. Ce qui compte : la part des t\u00e2ches \u00e9ligibles r\u00e9ellement trait\u00e9es avec l’outil, et l’\u00e9cart entre les \u00e9quipes. Un \u00e9cart qui se creuse signale un probl\u00e8me d’accompagnement, pas d’outil.<\/p>\n\n\n\nLe probl\u00e8me n’est pas le POC. C’est ce qui vient apr\u00e8s.<\/h2>\n\n\n\n
Cinq raisons pour lesquelles l’adoption de l’IA ne passe pas \u00e0 l’\u00e9chelle<\/h2>\n\n\n\n
1. L’usage de l’IA n’est pas le m\u00eame selon le r\u00f4le<\/h3>\n\n\n\n
2. Un socle important de code existant change enti\u00e8rement l’\u00e9quation<\/h3>\n\n\n\n
3. Ce qui marche sur un produit ne se transpose pas m\u00e9caniquement<\/h3>\n\n\n\n
4. Les comp\u00e9tences d’int\u00e9gration produit ne sont pas celles de la R&D<\/h3>\n\n\n\n
5. Une grande organisation ne change pas de direction tous les quinze jours<\/h3>\n\n\n\n
La r\u00e9ponse : des t\u00eates de pont, pas un outil de plus<\/h2>\n\n\n\n
\n
Comment structurer un d\u00e9ploiement multi-\u00e9quipes et multi-technologies<\/h2>\n\n\n\n
Trois approches compar\u00e9es<\/h2>\n\n\n\n\n\n\n