Intégrer l'IA dans une entreprise établie : par où commencer

Vous n'avez pas une page blanche. Vous avez un produit en production, une codebase de cinq ans que trois personnes connaissent vraiment, une équipe qui a déjà survécu à deux réorganisations, et des rituels qui font tourner la boîte même les semaines où personne n'y pense. Et à peu près tout ce qu'on vous raconte sur l'IA semble écrit pour une startup dont le premier commit date d'hier.

Cet article s'adresse à ceux qui pilotent une entreprise qui existe déjà. Une scale-up qui a passé le product-market fit et dont la roadmap est pleine pour dix-huit mois. Un groupe avec ses équipes produit réparties sur plusieurs pays. La taille change les chiffres, pas la question : comment intégrer l'IA quand l'existant pèse aussi lourd que l'ambition, et pourquoi la plupart des tentatives s'arrêtent au stade où elles commençaient à coûter cher.

L'existant n'est pas ce qui bloque l'intelligence artificielle, c'est ce qu'elle amplifie

Le réflexe courant consiste à voir le legacy comme un handicap : si seulement on pouvait repartir propre. C'est une erreur de lecture. L'IA prend votre produit, votre code et votre organisation tels qu'ils sont, et elle les pousse plus loin dans la direction où ils allaient déjà. Un flux de travail clair accélère. Une zone de flou que personne ne voulait traiter remonte à la surface, plus vite que prévu.

Les chiffres de la rentrée vont dans ce sens. Une étude BearingPoint relayée le 1er octobre ne compte que 13 % d'entreprises en bonne voie dans leurs initiatives IA, et 34 % des répondants citent l'intégration avec leurs systèmes existants comme frein principal au passage à l'échelle. La part des entreprises ayant profondément intégré l'IA dans leurs opérations est passée de 7 % à 11 % en un an. Quatre points. Pendant que les modèles doublaient de capacité, l'adoption réelle avançait au rythme de l'intégration, pas au rythme des outils.

Greffer un outil n'est pas intégrer l'IA

Ce que font la plupart de ceux qui plafonnent, c'est greffer. Un copilote par développeur, un assistant sur le support, un agent qui résume les tickets. Chaque greffe améliore une personne. Aucune ne change la façon dont l'entreprise produit, et au bout d'un an on a cent licences, des démos qui impressionnent, et une vélocité qui n'a pas bougé sur les métriques qui comptent.

Une startup IA-native n'a pas ce problème : elle construit son organisation autour de la machine dès le premier sprint, parce qu'il n'y a rien à défaire. Une entreprise établie doit reconstruire autour, avec des gens déjà en poste, un produit qui ne doit pas s'arrêter et des clients qui ne veulent rien savoir de votre transformation. C'est un projet de transformation au sens plein, et il mérite ce qu'on accorde à un projet de transformation : un sponsor au comex, un périmètre, un budget. Pas une ligne de plus dans la facture SaaS.

Là où l'intégration bloque : 4 situations

Quand un dirigeant dit « on a trop d'existant pour aller vite sur l'IA », il mélange en général quatre choses. Elles freinent pour des raisons différentes, et la parade n'est jamais la même.

Le produit et ses données

Votre data model a grandi par couches. Des tables nommées en 2021 par un cofondateur parti depuis, un champ status qui veut dire deux choses selon le service qui l'écrit, des règles métier qui n'existent que dans le code. Pour un humain qui a l'historique, ça se navigue. Pour un modèle, c'est le contexte qu'on lui donne, et le contexte est le composant le plus souvent coupable quand la sortie déçoit : absent, il invente ; périmé, il ment ; trop large, il dilue ce qui compte. La première dette que révèle l'IA n'est pas technique, c'est une dette de description : votre produit n'a jamais eu besoin d'être expliqué à quelqu'un qui ne connaît rien.

La codebase

Il y a dans votre code des modules que plus personne n'ose toucher, et des endroits où un pattern sûr et un pattern fragile cohabitent sans qu'aucun commentaire ne les distingue. L'IA n'a pas d'intuition pour ça. Elle reproduit ce qu'elle voit, et elle le reproduit vite. Nous avons vu une équipe, bien outillée, découvrir qu'une faille d'autorisation antérieure à ses agents avait été réintroduite en série dans du code neuf : plus de cent cinquante occurrences, dont deux pires que l'original. La machine industrialise ce qu'on lui donne. La qualité si c'est de la qualité, le défaut si c'est un défaut.

Les façons de faire

Le wiki dit une chose, les pull requests en montrent une autre, et le process de mise en production réel tient dans la tête de la personne d'astreinte. Tant qu'une règle n'est qu'écrite, elle est de la documentation morte : personne ne la relit, et surtout pas un agent. Ce qui vaut pour une convention de code vaut pour un process d'onboarding client ou une règle de remise commerciale. Si la règle n'est pas exécutable, vérifiable par quelque chose qui bloque quand elle est violée, l'IA la contournera sans le savoir.

L'équipe

Votre équipe a déjà vu passer la migration cloud, le passage à Scrum, le monorepo, peut-être une refonte front qui a duré deux fois plus longtemps que prévu. Elle a appris à attendre. Dans toute équipe établie on retrouve les mêmes profils : quelques promoteurs qui ont déjà tout essayé le week-end, une majorité d'attentistes qui regardent si ça tient, et des défensifs, souvent les plus seniors, qui ont de bonnes raisons de l'être puisque c'est eux qu'on appelle quand ça casse. Aucun outil ne traite ça. Seule une démonstration sur leur propre terrain le fait.

Ce qui relie les quatre : les questions à se poser sont les mêmes pour une ligne de code et pour un process de facturation.

• Qu'est-ce qu'on donne à la machine comme matière ?
• Qui vérifie ce qui en sort ?
• Qui signe avant que ça parte chez un client ?

Une entreprise qui sait répondre pour son logiciel sait répondre pour le reste, et inversement.

3 questions à se poser avant d'intégrer l'IA en entreprise

PwC a mesuré au printemps que 20 % des entreprises captent près des trois quarts des gains économiques de l'IA. Ce qui sépare ce groupe des autres n'est pas un meilleur modèle ni un budget plus gros. Ce sont des décisions prises en amont, par la direction, avant qu'un seul outil soit déployé. Elles tiennent en trois arbitrages.

Que doit financer la machine ?

Une capacité de production qui coûtait beaucoup plus cher il y a deux ans se libère. Elle peut servir à faire la même chose avec moins de monde, ou à faire davantage avec la même équipe : attaquer un marché, tenir une roadmap qu'on avait renoncé à tenir. Deux scale-ups observées à Singapour ont pris les deux chemins opposés avec la même machine. Ce choix n'appartient pas au CTO. Tant qu'il n'est pas tranché, chaque équipe optimise pour sa propre survie, et la transformation se fait contre elle.

Où a-t-on le droit de toucher ?

Le piège le plus documenté des transformations qui échouent est d'avoir visé « la transformation » plutôt qu'un périmètre. Un module, un flux, un parcours client. Quelque chose d'assez petit pour être mesuré avant et après, et d'assez réel pour que l'équipe le reconnaisse. Borner le périmètre, c'est aussi décider ce qu'on ne touche pas encore : les zones où une erreur coûte trop cher pour qu'on y apprenne.

Qui supervise, et qu'est-ce qui bloque ?

Avant d'accélérer la production, construire le contrôle. Quelles vérifications arrêtent la ligne automatiquement, qui relit ce qui sort, qui a le dernier mot avant un déploiement ou un envoi client. Les équipes qui posent ce cadre d'abord constatent une chose contre-intuitive : la gouvernance cesse d'être un frein. Quand la supervision est construite dans le dispositif, l'essentiel de ce qu'exige la réglementation est déjà couvert, et les équipes avancent plus vite parce qu'elles savent ce qui est permis.

Trois décisions, aucune technique. C'est pour cela qu'elles sont si souvent sautées : on les confond avec des détails d'exécution qu'on réglera plus tard, et plus tard est le moment où le pilote plafonne.

Les 90 premiers jours quand on a un existant

La séquence qui suit est celle que nous appliquons. Elle n'a rien d'original dans sa forme, et c'est voulu : ce qui la distingue d'un plan de déploiement d'outil, c'est que chaque phase prend l'existant comme point de départ au lieu de l'ignorer.

1. Diagnostiquer

Quinze minutes par développeur, script fixe, et le même exercice côté métier sur le périmètre choisi. On score la maturité de l'équipe, pas des individus, sur les quatre niveaux. On type les résistances. Surtout, on localise le goulot réel : est-ce qu'on perd du temps à écrire, à relire, à tester, ou à décider quoi construire ? Dans une entreprise établie, il est rarement là où la direction le pense. Livrable : une carte de chaleur de la maturité par équipe et par étape.

2. Démontrer

Un champion volontaire, 20 % de son temps, et un cas d'usage pris dans le périmètre borné plus haut. Pas un sujet neuf : un module que tout le monde connaît, pour que la comparaison avant/après soit indiscutable. Le champion binôme avec un attentiste, pas avec un autre promoteur. Démo en show-and-tell, avec des chiffres, devant ceux qui doutent. Livrable : un cas documenté, avec son coût réel.

3. Cadrer et piloter

La règle d'une page : ce que la machine fait, ce que l'humain garde, ce qui bloque automatiquement. Le filet de contrôle devient bloquant dans la chaîne d'intégration. Le modèle de déploiement s'adapte à la taille : une équipe entière sous dix personnes, par squad entre dix et trente, via une équipe plateforme au-delà. Office hours hebdomadaires pour absorber les questions. Livrable : le runbook de l'équipe.

4. Itérer

On mesure la transformation, jamais l'adoption : taux d'échec des changements, code repris sous deux semaines, complexité, duplication. Le pourcentage de code écrit par l'IA n'est pas un objectif. Rétrospective mensuelle sans blâme, où l'on juge le process et pas les gens. Les attentistes convaincus deviennent les champions du périmètre suivant. Et révision trimestrielle du cadre, parce qu'il sera périmé en six mois.

Ce plan ne demande ni recrutement ni réorganisation pendant ses 90 jours. Il demande une chose plus rare : que la direction tienne les trois décisions prises au départ pendant qu'une équipe apprend sous ses yeux, avec des résultats irréguliers les premières semaines.

Le goulot ne sera jamais l'IA générative

Dans une entreprise qui existe déjà, la machine ne manquera jamais de choses à produire. Le backlog est plein, les demandes métier s'accumulent, les clients attendent. Ce qui manquera, c'est la vitesse à laquelle quelqu'un tranche ce qu'on lui confie, ce qu'on garde, et ce qu'on arrête de faire parce que ça ne rapporte plus.

L'existant n'était pas l'obstacle. Il était le test : une entreprise qui sait expliquer son produit, exécuter ses règles et décider vite était déjà prête. Les autres découvrent avec l'IA ce qu'elles repoussaient sans elle.

FAQ

Par où commencer l'IA dans une entreprise qui a déjà un produit et une codebase ?

Par un périmètre borné, pas par un outil. Choisissez un module ou un flux que l'équipe connaît par cœur, mesurez son état actuel, et faites-y la démonstration avec un volontaire. La comparaison avant/après sur un terrain connu vaut tous les pilotes sur des sujets neufs. Le déploiement d'outils vient après, une fois le cadre de supervision posé.

Faut-il nettoyer la dette technique avant d'intégrer l'IA ?

Pas toute, et pas avant. La dette que révèle l'IA est d'abord une dette de description : ce que votre produit et votre code supposent connu de celui qui y travaille. Documenter le contexte du périmètre choisi (conventions, règles métier, zones interdites) suffit pour démarrer. Le reste de la dette se traite au fil des périmètres, quand la machine la rend visible.

Combien de temps avant de voir un résultat mesurable ?

Un premier cas documenté avec son coût réel arrive en cinq semaines si le périmètre est bien borné. Les métriques de transformation (taux d'échec des changements, code repris, complexité) demandent un trimestre pour être lisibles. Méfiez-vous des gains visibles en deux semaines : ils mesurent en général l'adoption, pas la transformation.

L'IA va-t-elle remplacer les équipes déjà en place ?

C'est une décision de direction, pas une conséquence technique. La même capacité de production peut financer une réduction d'effectifs ou un plan de conquête, et des entreprises comparables ont pris les deux chemins. Ce qui est certain, c'est que le métier change : l'équipe passe de produire à cadrer, contrôler et décider. Ceux qui l'ont vécu dans un contexte établi disent que l'expertise ne disparaît pas, elle migre dans le système et ses contrôles.