L’IA qui marche en démo et casse en silence

Un dimanche soir, un responsable motivé branche un agent sur le logiciel de gestion et automatise le tri des demandes clients. Le lundi, la démonstration fait son petit effet : ça lit, ça classe, ça répond, ça va vite. Les outils n’ont jamais été aussi accessibles, et l’idée s’impose d’elle-même autour de la table : pourquoi payer quelqu’un pour ça, on peut très bien le faire nous-mêmes.

Et c’est une bonne nouvelle. Tester, monter une démo, voir ce que l’IA sait faire sur ses propres données, c’est la meilleure façon de comprendre où elle peut servir, sans attendre l’autorisation de personne. Ces initiatives sont précieuses : elles font monter toute l’entreprise en culture IA, elles révèlent des cas d’usage qu’aucun consultant n’aurait devinés. Il faut les encourager, pas les brider.

La nuance se joue au pas d’après. Intégrer l’IA soi-même paraît à portée de main, mais entre la démonstration qui épate le lundi et le système qui tourne tous les jours pendant un an, il y a un fossé. Si intégrer l’IA est devenu un métier, ce n’est pas par goût de la complexité : c’est parce que franchir ce fossé sans la compétence ne se paie pas le jour où on branche l’outil. Ça se paie plus tard.

« On le fait nous-mêmes » : le bon réflexe, et où il dérape

Soyons justes : la tentation est légitime. Les abonnements coûtent quelques dizaines d’euros, l’interface se manipule sans écrire une ligne de code, et un collaborateur dégourdi assemble en un week-end ce qui aurait demandé un prestataire il y a deux ans. Pour un usage ponctuel et isolé, ça marche, et c’est tant mieux.

Le malentendu commence quand on confond « faire fonctionner une démonstration » et « faire tourner un système en production ». La première impressionne en réunion. La seconde doit résister tous les jours, sur tous les cas, pendant des mois, au milieu d’une organisation qui change. Entre les deux, il y a tout ce que la démonstration ne montre pas.

Ce qui se voit en démo, ce qui ne se voit pas

Une démonstration réussit pour une raison qu’on oublie vite : elle se déroule sur un terrain préparé. Un cas propre, des données triées pour l’occasion, un scénario qui tombe juste. C’est utile pour convaincre, c’est trompeur pour décider.

La partie invisible est précisément celle qui coûte cher. Qui gère les exceptions, ces « neuf fois sur dix, sauf que » qui font le quotidien d’un service ? Comment l’outil se branche-t-il proprement sur les données réelles, souvent éparpillées entre un logiciel de gestion, des fichiers et trois boîtes mail ? Que se passe-t-il quand un processus évolue ? Et surtout : qui s’en occupe le jour où ça déraille ? Ces questions ne se posent pas en démonstration. Elles se posent en production, et savoir y répondre suppose que l’entreprise soit prête avant même de brancher quoi que ce soit.

La catastrophe à retardement

Reprenons l’automatisation du tri des demandes clients. Pendant des mois, elle tourne sans bruit, et tout le monde l’oublie, ce qui est le plus beau compliment qu’on puisse lui faire. Puis l’entreprise ajoute une gamme de produits, modifie un statut, change un libellé. L’automatisation, elle, n’est pas au courant : elle continue de classer selon l’ancienne logique. Les demandes d’un nouveau type tombent dans un angle mort.

Personne ne le remarque, parce qu’on ne surveille pas un outil qui « marchait ». Trois mois plus tard, des clients n’ont jamais reçu de réponse, un autre a été facturé de travers, et la personne qui avait bricolé l’agent a changé de poste sans rien documenter. Il faut alors tout reprendre, comprendre un assemblage que personne n’a conçu pour durer, et réparer dans l’urgence ce qu’on aurait pu prévoir au départ.

Et le tri des demandes n’est qu’une forme du problème. Prenons un tableau de bord alimenté automatiquement : un agent va chercher des chiffres dans plusieurs fichiers et sort chaque lundi un récapitulatif soigné, sur lequel la direction s’appuie. Un jour, quelqu’un renomme un fichier source ou déplace une colonne. L’agent ne proteste pas : il continue, avec des cases vides ou des valeurs décalées, et le rapport garde la même allure rassurante. On finit par trancher sur des chiffres faux sans le savoir, ce qui est pire que de ne pas avoir de rapport du tout.

Plus discret encore : pour gagner du temps, on glisse des données clients dans un outil grand public, sans voir qu’elles quittent l’entreprise et nourrissent un service tiers. Rien ne casse, rien ne clignote en rouge. Le risque, lui, est bien là, et il porte un nom et des sanctions dès qu’il s’agit de données personnelles.

C’est la signature d’une intégration mal née : elle ne provoque pas une panne spectaculaire le premier jour, elle accumule une dette silencieuse. Des automatisations fragiles que personne ne maîtrise, des données qui circulent sans contrôle, des décisions prises sur des sorties que plus personne ne vérifie. La facture n’arrive pas tout de suite, mais elle arrive, et elle est toujours plus lourde que le coût qu’on a cru éviter.

Tenir la vue d’ensemble, c’est un métier

La différence ne tient pas à l’outil, qui est le même pour tous. Elle tient à quelqu’un qui porte la vue d’ensemble dès le départ : anticiper les cas tordus, brancher proprement sur l’existant, prévoir la maintenance, documenter, garder en tête comment chaque brique s’inscrit dans le reste. C’est ce regard qui transforme une démonstration en système qui dure.

Ce regard a un nom, c’est même un rôle qui émerge dans les entreprises : un responsable capable de tenir l’IA de bout en bout. Reste à décider comment l’obtenir, en interne ou en s’appuyant sur des gens dont c’est le métier, ce que recoupe la grille entre autonomie, accompagnement et appui externe posée dans l’article sur le métier de l’intégration.

L’IA bricolée ne coûte rien le jour où on la branche. Elle se facture le jour où elle casse, et ce jour finit toujours par arriver. Payer la compétence avant revient presque toujours moins cher que réparer après.