Quand un dirigeant accepte de consacrer une journée à l'intelligence artificielle avec un intervenant extérieur, il attend généralement d'en ressortir avec quelque chose qui fonctionne. Un automatisme, un robot, une chaîne qui tourne toute seule.
C'est la mauvaise attente, et elle produit régulièrement la même déception 6 semaines plus tard : la chose fonctionne encore, mais plus personne ne sait pourquoi elle a été réglée ainsi, ni comment la modifier quand le contexte change.
Le cas, et il est ordinaire
Prenons un bureau d'études du bâtiment engagé dans une consultation. Sa boîte de messagerie porte un arriéré d'environ huit mille messages, et elle en reçoit une cinquantaine par jour.
Personne dans cette entreprise ne considère cet arriéré comme un problème d'intelligence artificielle. C'est un problème de temps, et il est traité comme tel : on classe quand on peut, c'est-à-dire rarement.
Une après-midi de travail a produit le résultat suivant : cinquante-quatre messages reçus et cent douze envoyés classés, quarante-trois pièces jointes déposées au bon endroit, et quarante et un doublons évités.
Ces chiffres sont modestes et c'est volontairement qu'ils le sont. Ils ne mesurent pas une automatisation à grande échelle. Ils mesurent un cas mené jusqu'au bout, sur une affaire réelle, avec ses exceptions.
Pourquoi le courriel est un objet difficile dans le bâtiment
Dans la maîtrise d'œuvre, un message n'est pas une communication. C'est un écrit qui engage.
Une réserve formulée par courriel, un accord donné en réponse, une pièce transmise à une date, tout cela peut être produit des années plus tard, dans une discussion sur les responsabilités. C'est ce qui rend le classement coûteux, et c'est ce qui interdit d'aller vite : un message mal classé n'est pas une gêne, c'est une pièce qu'on ne retrouvera pas le jour où elle comptera.
Toute personne qui propose d'automatiser ce tri sans avoir compris cela propose une économie de temps contre un risque qui ne se voit pas encore.
Trois règles, et chacune est née d'une erreur commise le jour même
Un mot-clé seul ne qualifie rien. Le premier réglage classait sur les termes du message. Il s'est trompé immédiatement, parce que le même mot n'a pas le même sens selon qui l'emploie. Ce qui qualifie un message, c'est le rôle de celui qui l'envoie. Le mot ne vient qu'ensuite.
Les pièces jointes des messages envoyés ne s'extraient jamais. Elles semblent pourtant utiles : ce sont celles qu'on a transmises. Mais elles existent déjà ailleurs, dans le dossier d'où elles sont parties, et les extraire fabrique des doublons sans en fabriquer la trace. Les quarante et un doublons évités viennent en grande partie de cette règle.
Le rôle est relatif à l'affaire, pas à l'entreprise. C'est la règle la moins intuitive et la plus structurante. Une entreprise qui est cliente sur une opération est candidate sur une autre, et sous-traitante sur une troisième. Un annuaire central qui lui attribue un rôle unique se trompera sur deux affaires sur trois. Ce qu'il faut, c'est un fichier de rôles par affaire, ce qui paraît plus lourd et se révèle plus simple.
Un dispositif réglé sur une intuition fonctionne jusqu'au premier cas qu'on n'avait pas prévu. Un dispositif réglé sur une erreur qu'on a commise et comprise tient beaucoup plus longtemps.
Olivier Indovino, IARH Consulting
Ce que le dirigeant emporte réellement
À la fin de cette journée, ce qui a de la valeur n'est pas la chaîne qui classe les messages. C'est un fichier de réglages de 3 pages, lisible par quelqu'un qui n'est pas informaticien.
Il contient les mots de reconnaissance retenus, les destinations de classement, le rôle de chaque partie sur cette affaire, et le journal de ce qui a été fait. Rien de plus.
Sa valeur tient à deux propriétés que l'automatisme n'a pas. Il est corrigible par le dirigeant lui-même : quand une nouvelle entreprise entre sur l'affaire, il ajoute une ligne, sans appeler personne. Et il est recopiable pour l'affaire suivante : la structure est la même, seuls les rôles changent.
Un automatisme livré sans ce fichier est un objet opaque dont la durée de vie est celle de la mémoire de celui qui l'a réglé. Le même automatisme livré avec est un outil qui appartient à l'entreprise.
Ce que cela change à la façon de commander une journée d'IA
Trois questions à poser avant de s'engager, à qui que ce soit.
Qu'est-ce que j'emporte à la fin de la journée, sous une forme que je peux lire et modifier moi-même ?
Le travail portera-t-il sur un cas mené jusqu'au bout, exceptions comprises, ou sur trois cas entamés ? Un cas fini enseigne ce que trois cas entamés ne montrent jamais : ce qui casse.
Et si la personne qui a réglé le dispositif n'est plus disponible dans 6 mois, que reste-t-il ?
Une entreprise qui obtient une réponse claire aux trois a commandé un transfert de méthode. Une entreprise qui n'en obtient aucune a commandé une démonstration.
C'est exactement la différence que nous mettons dans l'offre d'automatisation des processus support, et c'est l'objet d'un diagnostic dirigeant.