« Qu’est-ce que l’IA pourrait faire chez nous ? » La question revient à chaque comité de direction et elle est mal posée. Elle invite à partir des capacités de la technologie, ce qui produit une liste d’idées séduisantes dont aucune ne se rattache à un coût réel. Six mois plus tard, l’entreprise a un abonnement, deux essais abandonnés et le sentiment d’avoir raté quelque chose.
La question utile est l’inverse : parmi les tâches que nous faisons déjà, lesquelles nous coûtent le plus cher pour ce qu’elles rapportent ? On ne cherche pas où mettre de l’IA, on cherche où ça fait mal. La technologie arrive après, et parfois elle n’arrive pas.
Partir des tâches, jamais des outils
Un inventaire utile se fait auprès des personnes qui exécutent, pas auprès de celles qui décident. Trois questions, une heure par service, un tableur :
- Qu’est-ce que vous refaites plusieurs fois par semaine, à l’identique ?
- Qu’est-ce qui vous fait attendre quelqu’un d’autre ?
- Qu’est-ce que vous faites parce que « c’est comme ça », sans savoir à quoi ça sert ?
La troisième question est la plus rentable du lot. Elle ne mène pas à un projet d’IA mais à une suppression, et une tâche supprimée coûte moins cher que la même tâche automatisée. Faites ce tri d’abord : il est gratuit.
La grille à deux axes
Chaque tâche survivante se place sur deux axes simples, et deux seulement. Toute grille plus riche devient un exercice de remplissage.
- La fréquence : combien de fois par semaine ? C’est ce qui détermine si l’investissement se rembourse.
- Le coût d’une erreur : que se passe-t-il si la décision est fausse une fois sur cinquante ? C’est ce qui détermine le niveau de contrôle humain, donc le vrai budget.
| Erreur peu coûteuse | Erreur coûteuse | |
|---|---|---|
| Tâche fréquente | Commencez ici. Gain rapide, risque faible, apprentissage réel pour l’équipe. | Projet sérieux, à instruire : contrôle humain obligatoire, traces, budget conséquent. |
| Tâche rare | Laissez de côté. Le temps de conception ne se rembourse pas. | Ne touchez pas. Rareté et gravité sont la pire combinaison : personne ne détectera la dérive. |
Le premier projet se choisit dans la case en haut à gauche, sans exception. Non parce qu’elle est la plus rentable — elle l’est rarement — mais parce que c’est la seule où l’entreprise peut se tromper sans conséquence tout en apprenant ce que ces outils font réellement.
Trois questions qui éliminent la moitié des idées
Avant tout chiffrage, chaque candidat passe trois filtres. Une seule réponse négative suffit à repousser le sujet.
Où vit la donnée nécessaire ? Si elle est dans un logiciel qui expose ses données, le projet est un projet d’intégration. Si elle est dans des PDF scannés, des tableurs sur des postes individuels ou la mémoire d’un collaborateur, le projet commence par un chantier de données qui représente souvent l’essentiel du budget. Ce n’est pas disqualifiant, mais il faut le savoir avant de s’engager.
Qui vérifie, et avec quel temps disponible ? Un cas d’usage sans propriétaire identifié ne survit pas au troisième mois. Il faut un nom, et un créneau réel dans l’emploi du temps de cette personne.
Comment saura-t-on que ça marche ? La réponse doit être un chiffre qu’on sait déjà mesurer aujourd’hui. « Gagner du temps » n’en est pas un ; « réduire de trois jours à un jour le délai de traitement d’une commande fournisseur » en est un. Si le chiffre n’existe pas encore, mesurez-le un mois avant de démarrer, sinon vous n’aurez aucun point de comparaison.
Deux familles de cas remontent en tête de liste dans presque toutes les PME que nous accompagnons : l’automatisation d’un traitement répétitif, parce que le volume et la règle y sont clairs, et un assistant sur le site qui répond à partir de vos propres contenus, parce que les questions reçues se répètent. Ce n’est pas une fatalité, c’est simplement là que se concentrent les tâches fréquentes dont une erreur ne coûte pas cher.
Le prototype de deux semaines
Un cas d’usage retenu ne se planifie pas sur six mois : il se teste sur deux semaines, avec un objectif volontairement étroit. Pas une intégration complète, pas d’interface soignée, pas de reprise de l’historique. On traite quelques dizaines de cas réels — pas des exemples choisis — et on regarde trois choses.
- Le taux de traitement correct sur des cas que personne n’a triés à l’avance.
- La nature des échecs : sont-ils concentrés sur un type de cas identifiable, ou dispersés ? Concentrés, ils se corrigent par une règle. Dispersés, le cas d’usage est probablement mal découpé.
- Le temps de vérification réel, chronométré. C’est lui qui décide si le gain existe, et c’est celui qu’on oublie toujours de mesurer.
Un prototype qui échoue au bout de deux semaines est un bon résultat : il a coûté deux semaines. Le mauvais scénario est le projet de six mois qui découvre la même chose à la fin.
Ce que le premier projet doit produire, au-delà du résultat
Le premier cas d’usage a une fonction que son cahier des charges ne mentionne jamais : apprendre à l’entreprise à travailler avec ces outils. Réussi, il laisse quatre choses derrière lui.
- Une équipe qui sait distinguer ce que la technologie fait bien de ce qu’elle prétend faire.
- Un inventaire de vos données bien plus honnête que celui d’avant le projet.
- Une habitude de mesure : on sait désormais chiffrer un avant et un après.
- Une liste de cas d’usage reclassée, parce que six mois de pratique déplacent toujours les priorités du tableau initial.
C’est pour cette raison qu’un premier projet doit être petit, visible et sans danger. Sa valeur n’est pas dans le gain qu’il produit, mais dans la justesse qu’il apporte à la décision suivante — celle qui portera, elle, sur un sujet qui compte.
