Par où commencer l’adoption de l’IA dans une petite entreprise

Dans une petite entreprise, la conversation sur l’intelligence artificielle commence presque toujours à l’envers. Quelqu’un a vu un outil, l’a essayé un dimanche, et le lundi il demande comment l’introduire dans l’entreprise. Un an plus tard, il y a trois abonnements actifs, deux dont personne ne se sert et aucun processus qui ait changé.

Le gaspillage ne se produit pas au moment de la mise en œuvre. Il se produit avant : en choisissant l’outil avant de choisir le problème.

La première décision n’est pas quoi acheter

Commencez par identifier un processus concret qui vous fait déjà mal, qui se produit de nombreuses fois par mois, dont le résultat peut se mesurer et dont l’erreur reste tolérable. L’outil se choisit ensuite, quand on sait déjà ce qu’il doit résoudre. Parfois la réponse finit par être plus simple et moins chère que prévu.

C’est l’un des meilleurs résultats possibles d’un diagnostic. Une bonne partie de ce que l’on envisage de résoudre avec l’IA se résout mieux en mettant de l’ordre dans la donnée, en connectant deux systèmes ou en supprimant une étape qui n’a plus de sens : cela arrive plus vite, coûte moins cher et prépare le terrain pour le moment où il faudra vraiment automatiser.

Les quatre questions qui mettent de l’ordre dans la conversation

1 · Combien de fois par mois se produit le processus que vous voulez automatiser ?

Automatiser a un coût fixe de démarrage — analyse, construction, tests, corrections des premières semaines — et un coût variable faible. C’est pourquoi la fréquence commande : un processus qui se produit quatre cents fois par mois paie son automatisation même si le gain par occurrence est de deux minutes. À quatre fois par mois, en revanche, le démarrage met très longtemps à se rembourser, et mieux vaut le garder pour plus tard.

Mieux vaut compter avant de décider. C’est un calcul de dix minutes et il réserve en général des surprises dans les deux sens : des processus qui semblaient constants se produisent peu, et d’autres que personne n’avait en tête se révèlent être les plus répétés.

2 · Combien coûte aujourd’hui le fait de mal faire ce processus ?

Non pas ce que coûte le faire : ce que coûte le faire mal. Un rendez-vous perdu faute d’avoir répondu à un message à neuf heures du soir, un devis parti avec l’ancien prix, une commande expédiée au mauvais client.

Ce chiffre — le coût de l’erreur, pas celui du travail — est celui qui justifie en général le projet, et c’est celui qui ne figure presque jamais dans le tableur avec lequel on demande un devis.

3 · Où vit aujourd’hui l’information qui servirait de référence à l’automatisation ?

C’est la question qui arrête le plus de projets, et il vaut mieux qu’elle les arrête tôt.

Un système automatisé a besoin de consulter la vérité quelque part. Si l’horaire réel est dans la tête du responsable, si l’inventaire tient dans trois fichiers qui ne concordent pas, si le prix en vigueur dépend de la personne à qui l’on demande, il n’y a rien à consulter. L’IA ne met pas de l’ordre dans une donnée désordonnée : elle la répète avec plus d’assurance.

Quand la réponse à cette question n’est pas claire, le premier projet n’est pas un projet d’IA : c’est mettre la donnée en un seul endroit. Cela sonne moins moderne et c’est ce qui rend possible tout le reste, donc ce n’est pas une étape perdue mais la première. C’est aussi un travail que nous faisons : ordonner l’information et relier entre eux les systèmes que vous avez déjà font partie du métier, et c’est souvent l’étape qui débloque tout ce qui venait derrière.

4 · Que se passe-t-il si le système se trompe ?

Aucun système ne tombe juste cent pour cent du temps, ni l’automatique ni celui qu’actionne une personne fatiguée un vendredi à six heures. La différence tient à ce que l’on construit autour pour qu’une défaillance se détecte et se corrige avant d’atteindre qui que ce soit, et cela se conçoit différemment selon ce qui est en jeu. Mieux vaut donc classer les candidats en trois groupes :

• Ce qu’une personne relit avant que cela ne sorte — classer des courriels, rédiger un premier brouillon, résumer une réunion, proposer des réponses. Le système propose et vous décidez, donc le pire qui puisse arriver est d’écarter un brouillon. Commencez par là : c’est là que l’on voit comment il se comporte avec tout sous contrôle, et là que l’équipe prend confiance.
• Ce qui parle au client — prendre rendez-vous, confirmer, rappeler, répondre aux questions fréquentes. Ici le travail consiste à ce que le système n’improvise pas : il consulte l’horaire et le prix dans votre système au lieu de les inventer, et il passe la conversation à une personne dès que quelque chose ne colle pas. Bien construit, ce qui pourrait être un rendez-vous mal posé reste une conversation que quelqu’un reprend.
• Ce que l’on ne laisse jamais entre les mains du système — encaisser, facturer, expédier, tout ce qui a une conséquence juridique ou sanitaire. Ici le système fait le gros du travail et le laisse prêt, et une personne approuve avant que cela ne sorte. Ce n’est pas une limite de la technologie : c’est une décision de conception, et elle laisse presque tout le travail fait — il ne reste qu’à lire et à approuver.

La règle que nous appliquons chez nous est simple : aucun changement n’arrive à un système en production sans qu’une personne responsable l’approuve. S’y ajoutent les trois choses qui font qu’une défaillance se voit à temps — un journal de ce que le système a fait, une alerte quand quelque chose sort du prévu, et un moyen de revenir en arrière. Ce n’est pas de la prudence décorative : c’est ce qui permet de dormir quand le système répond au milieu de la nuit.

À quoi ressemble un premier projet qui réussit

Un premier projet raisonnable a quatre traits, et aucun n’est « qu’il utilise la technologie la plus récente ».

Les quatre erreurs qui coûtent le plus cher

1. Acheter l’outil en premier. L’outil se choisit quand le problème est déjà décrit. À l’envers, c’est le problème qui se déforme pour tenir dans l’outil.
2. Commencer par le plus visible. Ce qui se voit de l’extérieur est en général le plus délicat. Mieux vaut que le premier projet soit interne, là où une erreur se corrige sans qu’un client l’apprenne.
3. Ne pas décider quelle information peut sortir de l’entreprise. Cela se règle en un après-midi et évite de sérieux désagréments : c’est dans quelles données ne devraient pas entrer dans un modèle d’IA.
4. Confondre pilote et production. Un pilote qui fonctionne dans une démonstration n’est pas prêt à s’occuper de clients. Entre les deux il y a des règles, une gestion des défaillances, une surveillance et une sortie vers une personne.

Que faire cette semaine

Sans rien engager, et en une heure :

1. Écrivez les cinq processus que votre équipe fait à la main le plus grand nombre de fois par mois.
2. À côté de chacun, indiquez combien de fois et ce que cela coûte quand cela tourne mal.
3. Marquez à part ceux dont l’information ne vit encore dans aucun système. Ils ne sont pas écartés : ce qui change, c’est par où l’on commence, parce que cette donnée doit être mise quelque part avant d’automatiser quoi que ce soit. C’est un travail avec un début et une fin, et il est souvent plus court qu’il n’y paraît.
4. Parmi ceux dont l’information est bien dans un système, choisissez celui dont l’erreur coûte le moins cher. C’est votre premier projet. Et si tous ont été marqués à l’étape précédente, vous savez déjà quel est le vôtre : mettre de l’ordre dans la donnée.

Si vous êtes prêt à commencer à automatiser et à intégrer l’IA dans votre entreprise, la division technique examine votre liste avec vous lors d’une réunion de trente minutes et vous conseille par lequel de vos processus commencer, pourquoi, et ce qu’il faudrait faire avant. Sans frais et sans engagement.

Questions fréquentes

Par où une petite entreprise commence-t-elle à utiliser l’IA ?

Par un processus concret qui se produit de nombreuses fois par mois, dont l’erreur est peu coûteuse à corriger et dont l’information vit déjà dans un système. L’outil se choisit après avoir décrit le processus, jamais avant.

Faut-il avoir des données en ordre avant d’utiliser l’IA ?

Pour tout ce qui consulte l’information de l’entreprise, oui. Un système automatisé a besoin d’une source de vérité à consulter ; si la donnée est répartie entre des fichiers qui ne concordent pas, le système répétera l’incohérence avec plus d’assurance qu’une personne n’en aurait.

Combien de temps prend un premier projet d’adoption de l’IA ?

Cela dépend du processus et de l’état de l’information. Un assistant sur un processus simple et bien défini peut être prêt en quelques jours ; un processus avec beaucoup d’exceptions ou avec des données dispersées prend des semaines. Toute estimation s’affine en regardant ces deux choses, alors demandez-la comme une fourchette et non comme une date. Ce qu’il convient en revanche de fixer d’emblée, c’est le moment où l’on décidera si le pilote continue ou s’arrête.

Faut-il embaucher quelqu’un de la technique pour adopter l’IA ?

Il n’est pas nécessaire d’embaucher qui que ce soit à demeure. La partie technique peut se contracter au projet, et pour une petite entreprise c’est en général la voie sensée : on paie le travail dont on a besoin au lieu d’un poste permanent, et on accède à une équipe qui a plus de métier qu’un seul recrutement n’en apporterait. Ce qui doit rester dans l’entreprise, en revanche, c’est le responsable du projet : quelqu’un qui réponde du résultat et qui connaisse le processus. Cette partie-là ne se sous-traite pas, et c’est elle qui décide si le projet réussit.