Réussir un projet d’automatisation en PME commence avant le choix de l’outil IA
Il y a quelques semaines, un projet d’automatisation dans une PME du nord de la France m’a rappelé une chose simple : avant de choisir un outil IA, il faut comprendre le problème. Et le vrai succès, c’est le moment où l’équipe n’a plus besoin de moi.
Depuis 2018, avec Machine Learning Lab, j’ai accompagné plus de 200 entreprises. S’il y a une chose que ces projets m’ont apprise, c’est que la réussite d’un projet d’automatisation se décide rarement au moment où l’on choisit l’outil. Elle se décide avant, quand on prend le temps de regarder le problème en face. Voici ce que je vois revenir, projet après projet.
| Commencer par l’outil IA | Commencer par le problème | |
|---|---|---|
| Première question | « Quel outil IA choisir ? » | « Est-ce vraiment un problème d’IA ? » |
| Rôle de l’équipe | Utilisatrice d’un outil livré | Actrice qui construit la solution |
| Quand le processus change | On rappelle le prestataire | L’équipe modifie elle-même |
| Ce qui reste après mon départ | Un outil | Une équipe autonome |
Un projet d’automatisation dans une PME du nord de la France
Il y a quelques semaines, je me suis retrouvé dans une PME du nord de la France. Le problème n’avait rien de spectaculaire. Pas d’agents autonomes, pas de RAG, pas de modèles multimodaux, pas de démonstration futuriste. Rien de ce qui fait les gros titres des newsletters sur l’IA.
Simplement une personne qui passait plusieurs heures par semaine à exporter un fichier Excel depuis un logiciel, à le nettoyer manuellement, puis à le reformater pour pouvoir l’importer dans un autre logiciel incapable de comprendre le premier. Chaque semaine, le même rituel : les mêmes colonnes à déplacer, les mêmes lignes à corriger, la même attention pour ne rien oublier, parce qu’une erreur dans un fichier comme celui-là finit toujours par se retrouver plus loin dans la chaîne.
Le genre de problème qui ne fait rêver personne sur LinkedIn. Le genre de problème qui coûte pourtant des centaines d’heures de travail par an. Et c’est souvent là, dans ces tâches invisibles que personne n’ose appeler un projet, que se cachent les gains les plus concrets.
Le problème n’était pas l’absence d’intelligence artificielle
En discutant avec l’équipe, je me suis rendu compte que le problème n’était pas l’absence d’intelligence artificielle. Le problème était un système d’information figé dans le temps.
Des logiciels anciens, qui ne se parlaient pas entre eux, des exports Excel partout, des copier-coller manuels, des processus connus d’une seule personne, avec toute la fragilité que cela implique le jour où cette personne est absente. Et des tâches répétitives que tout le monde considérait comme normales, simplement parce qu’elles existaient depuis toujours.
Ce dernier point me frappe à chaque fois. Une tâche absurde qui dure depuis des années finit par devenir invisible. Plus personne ne la questionne, parce qu’elle fait partie du décor. Et si l’on arrive avec l’idée d’y mettre « de l’IA », on risque surtout d’ajouter une couche de technologie par-dessus un problème que personne n’a vraiment regardé.
Lire aussi : Maîtriser les outils IA commence souvent par un geste simple : oser cliquer.
Quelques heures plus tard, l’équipe n’avait plus besoin de moi
Alors nous avons ouvert un éditeur de texte. Pas une plateforme à abonnement, pas un logiciel coûteux : un simple éditeur, comme on en trouve sur n’importe quel ordinateur.
Quelques heures plus tard, nous avions construit ensemble une petite application HTML et JavaScript capable d’importer le fichier du système A et de générer automatiquement le fichier attendu par le système B. Ce qui occupait plusieurs heures chaque semaine devenait une opération automatique.
Pas de magie. Pas de révolution technologique. Juste un problème concret résolu.
Mais le plus important n’était pas l’outil. Le plus important était que les personnes présentes avaient compris comment il fonctionnait. Elles avaient participé à sa construction, étape par étape, elles savaient désormais le modifier elles-mêmes, si le format d’un fichier changeait ou si un nouveau besoin apparaissait.
Elles n’avaient plus besoin de moi. Et c’est cela que j’appelle Parler IA.
Lire aussi : Ce qu’on peut déléguer à l’IA (et ce qu’on ne devrait jamais lui confier).
Parler IA, c’est savoir quelles questions poser avant un projet d’automatisation
Parler IA, ce n’est pas connaître les cinq prompts secrets qui débloquent ChatGPT. Ce n’est pas mémoriser une liste de techniques dont la moitié seront obsolètes dans six mois. Ce n’est pas non plus devenir développeur ou spécialiste du machine learning.
Parler IA, c’est développer une forme d’autonomie intellectuelle face aux systèmes. C’est comprendre suffisamment leur fonctionnement pour pouvoir poser les bonnes questions, avant même de parler d’outil :
- De quoi ce système a-t-il besoin pour fonctionner ?
- Où se trouvent réellement les données ?
- Le problème est-il un problème d’IA ou un problème d’organisation ?
- Une automatisation simple serait-elle plus pertinente qu’un modèle de langage ?
- Quelles sont les hypothèses implicites derrière cet outil ?
- Quelles sont ses limites ?
- Quels sont les risques si l’on se trompe ?
Aucune de ces questions ne demande de savoir coder. Elles demandent de regarder le système dans son ensemble plutôt que la tâche isolée. Dans la PME du nord, la troisième et la quatrième question ont suffi à changer la direction du projet : ce n’était pas un problème d’IA, et une automatisation simple faisait très bien le travail.
Lire aussi : Comment devenir autonome face à l’IA ?
Les systèmes complexes ont rarement des réponses simples
Parler IA, c’est également accepter une idée inconfortable : les systèmes complexes ont rarement des réponses simples.
Actuellement, il y a tellement de promesses des solutions universelles, des prompts miracles ou des recettes applicables à toutes les entreprises, qu’il devient presque subversif d’adopter une posture différente : « Je ne sais pas encore. Regardons ensemble comment cela fonctionne. »
Cette phrase peut surprendre, parce qu’on attend souvent d’un consultant qu’il arrive avec la réponse. Mais cette posture n’est pas un signe de faiblesse. C’est une posture épistémologique : une manière de reconnaître la complexité sans en avoir peur, de remplacer la fascination par la compréhension, et de passer du statut d’utilisateur passif à celui d’acteur capable d’agir sur ses outils.
Lire aussi : Quel est le meilleur outil IA ? La seule réponse honnête.
L’agency, c’est comprendre suffisamment pour agir
Les Anglo-Saxons utilisent le mot agency. J’aime beaucoup ce terme. Ce n’est ni le pouvoir, ni la compétence technique. C’est quelque chose entre les deux.
L’agency, ce n’est pas tout savoir. C’est savoir que l’on peut comprendre suffisamment pour agir. Comprendre suffisamment pour expérimenter. Comprendre suffisamment pour ne plus dépendre entièrement d’experts, de consultants ou de gourous, moi compris.
À mes yeux, c’est ce que cette équipe a gagné ce jour-là, bien plus qu’un fichier qui se génère tout seul : la possibilité de comprendre et de transformer ses propres outils.
Ce que je vois quand un projet commence par l’outil
Je vois aussi, régulièrement, l’histoire inverse. Une tâche pénible est identifiée. Quelqu’un décide qu’il faut « de l’IA ». Un outil est acheté, souvent impressionnant en démonstration, parfois coûteux.
Quelques mois plus tard, il dort dans un coin. Personne ne sait le modifier. Chaque changement de processus oblige à rappeler le prestataire. Et il arrive que la personne qui passait ses heures sur le fichier Excel les passe désormais à contourner l’outil censé l’aider.
Parfois, on a même automatisé un problème qu’il aurait suffi de supprimer. On a figé dans un logiciel une tâche qui aurait disparu avec une simple décision d’organisation. Le projet ne s’effondre pas, il patine, et les heures continuent de se perdre avec une couche technique en plus à maintenir.
Dans la PME du nord, la différence ne tenait pas à la technologie. Elle tenait au fait que l’équipe avait compris son propre problème, et qu’elle avait construit la solution avec moi. Voilà pourquoi elle pouvait continuer seule.
Mon travail n’est probablement pas de faire de l’IA
Au fond, mon travail n’est probablement pas de faire de « l’IA ». Mon travail consiste plutôt à aider des personnes et des organisations à retrouver cette capacité d’agir face à des systèmes qui leur semblaient jusque-là opaques et intimidants.
Le jour où mes clients n’ont plus besoin de moi pour avancer, j’ai généralement l’impression d’avoir bien fait mon travail.
Si vous avez, vous aussi, un fichier Excel qui mange des heures chaque semaine, on peut le regarder ensemble. C’est ce que nous faisons chez Machine Learning Lab dans nos missions d’accompagnement stratégique en IA. Et pour que vos équipes puissent continuer sans nous, il y a la formation Comprendre, expérimenter et piloter les projets d’IA.
Pour aller plus loin :
- notre webinars
- nos formations IA pour vos équipes
- notre intervention IA pour le CODIR
- nos conférences IA
FAQ – Projet d’automatisation en PME
Par où commencer un projet d’automatisation dans une PME ?
Par le problème, avant l’outil. Il faut d’abord comprendre le processus concerné : combien de temps il coûte, où se trouvent les données, qui le maîtrise, et s’il relève vraiment de l’IA ou d’une simple réorganisation. Une partie des gains se trouve souvent avant même d’introduire un outil.
Faut-il de l’intelligence artificielle pour automatiser une tâche en PME ?
Pas toujours. Beaucoup de tâches répétitives se règlent avec une automatisation simple, sans modèle de langage ni IA avancée. La question à se poser est : ce problème demande-t-il de l’IA, ou une meilleure circulation de l’information entre les logiciels existants ?
Comment choisir un outil IA pour un projet d’automatisation ?
Après avoir compris le problème. Une fois le processus, les données et les contraintes clarifiés, le choix de l’outil devient beaucoup plus simple, et parfois inutile. Il faut aussi vérifier que l’équipe pourra le piloter et le faire évoluer sans dépendre d’un prestataire.
Pourquoi des projets d’automatisation échouent-ils en PME ?
Souvent parce que le problème a été mal posé au départ. Un outil est choisi sans que le processus soit compris, l’équipe ne sait pas le piloter, et la solution reste peu utilisée. Un projet réussi rend l’équipe capable de faire évoluer la solution elle-même.
Comment rendre une équipe autonome sur ses automatisations ?
En l’associant à la construction de la solution plutôt qu’en lui livrant un outil fini. Quand les personnes comprennent comment fonctionne une automatisation, elles peuvent la modifier, la corriger et l’étendre sans dépendre d’un expert.
Faut-il être technique pour piloter un projet d’automatisation ?
Non. Piloter un projet d’automatisation demande de comprendre le problème, les données et les enjeux, pas de savoir coder. C’est une compétence de décision et de discernement, accessible à un dirigeant ou à un responsable opérationnel.
Nos formateurs IA à Paris
Rencontrez nos formateurs IA à Paris.
