Le pivot qui a sauvé un projet d'IA vocale : penser terrain avant de coder

Des techniciens de maintenance interviennent chaque jour sur des chantiers, et savent, de tête, ce qu’un chantier va coûter en temps et en matériel. Le problème n’est pas là. Le problème, c’est que transformer cette connaissance en devis écrit prend du temps, alors ce n’est presque jamais fait à temps, ou pas fait du tout.

L’idée pour résoudre ce problème semblait toute simple : plutôt que de remplir un formulaire, le technicien parle. Il décrit son chantier à voix haute, et un système automatisé transforme cette description en devis structuré, prêt à être vérifié par un responsable.

Faites défiler pour voir les 6 étapes →

Une bonne idée sur le papier

La première version de cette idée ressemblait à un coup de téléphone. Le technicien ouvrirait Microsoft Teams, l’outil de messagerie et de visioconférence que son entreprise utilise déjà, et appellerait un assistant automatisé. Il lui dicterait son estimation comme il le ferait à un collègue au téléphone.

Sur le papier, ça tient parfaitement. Dans la réalité du travail sur le terrain, ça ne tient pas du tout.

Quatre obstacles trouvés avant d’écrire la moindre ligne de code

Avant de commencer à construire quoi que ce soit, l’équipe a vérifié que cette idée était réellement faisable. Elle a découvert quatre obstacles, chacun suffisant à lui seul pour faire échouer le projet tel qu’il était pensé.

D’abord, un problème tout bête : depuis un téléphone mobile, il est tout simplement impossible d’appeler ce type d’assistant automatisé. Cette fonction n’existe que sur ordinateur. Or les techniciens travaillent avec leur téléphone, pas devant un écran.

Ensuite, la solution de repli évidente, à savoir utiliser un vrai numéro de téléphone classique, a été écartée par la direction. Elle aurait obligé à payer un abonnement téléphonique supplémentaire, et surtout, elle aurait fait sortir l’enregistrement de l’environnement sécurisé de l’entreprise.

Troisième obstacle : envoyer un simple message vocal à l’assistant, comme on le ferait sur une messagerie classique, ne fonctionne pas non plus. Un problème technique connu chez Microsoft fait que ce type de message arrive sans le son.

Enfin, la dernière option, faire en sorte que l’assistant rappelle lui-même la personne pour recueillir sa réponse, demanderait une installation technique beaucoup trop lourde et coûteuse, pour capter à peine deux minutes d’enregistrement par jour et par technicien.

Une solution beaucoup plus simple

Une fois ces quatre obstacles posés côte à côte, le changement de cap a été rapide. Plutôt que de faire venir la voix du technicien par un appel, l’équipe a construit une toute petite application, directement intégrée à Teams, avec un seul bouton : Enregistrer.

Le technicien parle, réécoute ce qu’il a dit, valide, puis envoie. C’est tout. Plus besoin de téléphonie, plus de numéro à composer, plus de licence supplémentaire à acheter. L’identification de la personne se fait automatiquement, puisqu’elle est déjà connectée à Teams pour travailler.

Ce qu’il faut retenir

La leçon de cette histoire dépasse largement ce projet précis. Elle est simple à énoncer, mais facile à oublier quand on est pressé de construire quelque chose : avant de se demander ce qu’une intelligence artificielle va faire d’une information, il faut d’abord vérifier, sur le terrain, que cette information peut tout simplement arriver jusqu’au système.

Ici, le risque n’était jamais la qualité de la transcription ou la pertinence de l’analyse automatique. Le vrai risque, c’était de savoir si un technicien, avec son téléphone, dans les conditions réelles de son travail, pouvait tout simplement faire parvenir sa voix au système. C’est souvent là, et pas dans l’intelligence artificielle elle-même, que les projets échouent.

Tester cette hypothèse avant de construire quoi que ce soit coûte quelques jours. Le découvrir après avoir construit une installation technique complexe coûte plusieurs semaines.