L'automatisation IA en entreprise commence par une carte, pas par un outil

Tu as un Zapier qui tourne. Un Make aussi, monté par quelqu'un qui n'est plus là. Un scénario s'est cassé au printemps, personne ne l'a vu passer, une facture sur deux repart à la main. Tu as payé pour automatiser. Tu passes toujours tes vendredis dans un tableur à rattraper ce que le système a laissé tomber.

Ce n'est pas un problème d'outil, c'est un problème d'ordre. Une automatisation IA se pose sur un process déjà écrit, mesuré, réparé. Posée avant, elle met de la vitesse sur quelque chose de cassé. Elle te rend la même erreur plus vite et à plus grande échelle. La première étape n'est pas un abonnement, c'est une carte de ce qui se passe vraiment chez toi.

L'automatisation IA en entreprise, c'est quoi exactement ?

L'automatisation IA est le fait de confier à un programme une tâche qui demandait jusque-là un jugement humain simple : lire un document, classer une demande, rédiger une première version, décider vers qui router. Ce n'est pas un automatisme classique, qui exécute une règle fixe et s'arrête dès que l'entrée sort du cadre prévu.

La distinction compte au moment de choisir quoi automatiser. Une règle fixe suffit pour ce qui est parfaitement régulier, elle est plus rapide et moins chère. Le modèle sert là où l'entrée est sale : un mail écrit à la va-vite, un PDF fournisseur qui change de forme tous les trimestres, une demande client formulée en langage humain.

Pourquoi la plupart des projets d'automatisation n'arrivent-ils jamais en production ?

Parce qu'ils sautent une étape, presque toujours la première. On choisit l'outil avant d'avoir la carte des process, donc on automatise ce dont on se souvient au lieu d'automatiser ce qui coûte. Le montage marche en démonstration, rencontre le premier cas réel, puis personne ne sait plus ce qu'il était censé faire.

Luke Pierce, qui construit ce type de systèmes chez des PME, le dit sans détour : chaque projet IA raté qu'il a vu avait sauté une étape, en général la première. Ses chiffres de résultats ne sont sourcés nulle part et on ne les reprend pas. C'est sa séquence qui nous intéresse, pas ses résultats.Le fil de Luke Pierce

Tu n'as pas besoin de le croire sur parole, l'ordre se vérifie tout seul. Prends un process que tu n'as jamais écrit, automatise-le, puis demande à la personne qui l'exécutait ce qui a changé pour elle. Tu obtiendras la liste des cas que le montage ne gère pas. Cette liste est exactement la carte que tu n'as pas faite. L'ordre ne se démontre pas par autorité, il se démontre en essayant l'inverse.

Dans quel ordre faut-il s'y prendre ?

Six étapes, dans cet ordre, sans en sauter une : cartographier, consolider, modéliser la donnée, construire, brancher l'IA, automatiser. L'automatisation arrive en dernier, ce qui surprend à peu près tout le monde. C'est pourtant la seule position où elle tient dans le temps.

Qu'est-ce qu'on cartographie exactement ?

Chaque process, département par département, parcouru avec la personne qui l'exécute vraiment. C'est le détail qui change tout : la version du fondateur et celle de la personne qui fait le travail sont deux process différents. C'est la seconde qui tourne tous les jours.

• Le déclencheur : ce qui fait démarrer ce process, avec la personne qui s'en aperçoit.
• Chaque passage de main, parce que c'est là que les dossiers attendent.
• Chaque double saisie, parce que c'est la preuve que deux outils ne se parlent pas.
• Le temps réel du manuel, chronométré, jamais estimé de mémoire.
• Ce qui se passe quand ça rate : qui le voit, au bout de combien de temps.

Luke Pierce raconte que des fondateurs lui ont dit que la carte seule valait la mission. C'est cohérent avec ce qu'on voit sur le terrain : le document met au même endroit ce que personne n'avait jamais posé côte à côte. Il révèle en général deux ou trois trous que le dirigeant cherchait depuis des mois.

Que faire des quinze outils déjà en place ?

Trois piles, pas une de plus : absorber, garder, tuer. Tu absorbes ceux dont la seule valeur est que tes affaires sont rangées dedans. Tu gardes les spécialistes qui font vraiment un métier. Tu tues les doublons et les abonnements que plus personne n'ouvre.

• Absorber : l'outil ne fait que stocker et afficher. Sa valeur est dans tes données, pas dans lui.
• Garder : l'outil fait un métier que tu ne veux surtout pas refaire, ou que la loi encadre. La comptabilité, la messagerie, l'agenda, le logiciel réglementé.
• Tuer : deux outils font la même chose, ou personne ne s'y est connecté depuis six mois.

Le test qui tranche tient en une question. Si tu retirais cet outil demain, est-ce que tu perdrais une compétence, ou seulement un endroit où poser des fichiers ? Une compétence se garde. Un endroit où poser des fichiers se remplace.

Quand est-ce qu'on met enfin de l'IA dedans ?

Quand le process est écrit, que la donnée vit à un seul endroit, que l'équipe travaille déjà dans le nouveau système. À ce moment le modèle a de quoi juger, il n'a plus à deviner. Avant, tu lui demandes de compenser un désordre que tu n'as pas réglé.

Consolider et automatiser en même temps est le piège le plus courant, parce que les deux chantiers ont l'air de se ressembler. En réalité tu figes dans du code un process que tu étais justement en train de réparer. Le jour où tu le répares pour de bon, il faut tout refaire.

Comment savoir si tu es prêt à automatiser ?

Pose-toi ces cinq questions, dans l'ordre. Si tu réponds non à une seule, ta prochaine tâche n'est pas une automatisation, c'est ce qui manque pour répondre oui.

• Ce process est-il écrit quelque part, dans les mots de la personne qui l'exécute ?
• Sais-tu combien de temps il prend réellement, chronomètre en main ?
• La donnée dont il a besoin vit-elle à un seul endroit ?
• Sais-tu ce qui doit se passer quand il rate ?
• Quelqu'un chez toi le regardera-t-il une fois par semaine ?

Les questions qui fâchent

On peut sauter la cartographie quand la boîte est petite ?

C'est l'inverse. Petite, la carte se fait en quelques jours et elle est encore juste quand tu la termines. Grande, elle prend des semaines et une partie sera périmée avant la fin. Le seul cas où on l'allège, c'est quand un seul process compte vraiment. Il faut quand même l'écrire.

Est-ce que ça veut dire un an de chantier avant le premier résultat ?

Non. Les six étapes s'appliquent à un périmètre, pas à toute la boîte d'un coup. Tu prends le département qui a le plus d'heures manuelles, tu le traverses en entier, tu passes au suivant. Ce qui prend un an, c'est de vouloir tout consolider avant de livrer quoi que ce soit.

Et si mon équipe refuse de changer d'outil ?

Elle refuse en général d'apprendre un outil de plus, pas de changer. Ça se joue à l'étape 4 : si le nouveau système reproduit les vues telles qu'elle travaille déjà, elle voit qu'on lui retire des outils au lieu de lui en ajouter un. L'adoption est une conséquence du design, pas une affaire de conduite du changement.

Est-ce qu'on peut faire ça sans budget de développement ?

Les deux premières étapes ne demandent aucun développement, seulement du temps et de l'honnêteté sur ce qui se passe vraiment. Ce sont aussi celles qui font le plus de dégâts quand elles manquent. Commence par là : tu sauras ensuite ce qui mérite d'être construit, surtout ce qui ne le mérite pas.