L'IA en usine pour une PME : par où commencer

Si vous dirigez une PME manufacturière, vous avez sûrement entendu parler d'IA cent fois cette année. La vraie question n'est pas « est-ce que je devrais en faire ? ». C'est « par quoi commencer, sans y laisser six mois et un budget ? ».

Pour intégrer l'IA dans une PME manufacturière, la réponse tient en peu de choses : un problème coûteux et bien compris, un seul procédé, un petit essai avec de vrais documents, et quelqu'un sur le plancher qui veut que ça marche. Voici comment s'y prendre, et les pièges à éviter.

Pourquoi tant de premiers projets d'IA déraillent

Ce n'est pas d'abord un problème de technologie. Jayson Myers, chef de la direction de NGen (Next Generation Manufacturing Canada), le disait lors d'un webinaire d'AI4Manufacturing : selon une enquête menée avec Statistique Canada, plus de 60 % des entreprises interrogées n'avaient pas atteint leurs objectifs d'affaires avec des technologies de fabrication avancée. Sa conclusion (traduction) : « Ce n'est pas un problème de technologie. C'est une question de gestion de la technologie pour atteindre des objectifs d'affaires. » (webinaire)

Ce chiffre porte sur les technologies de fabrication avancée en général, pas sur l'IA seulement. Mais le message vaut pour l'IA : les projets échouent quand on achète un outil avant de savoir quel problème il règle.

Étape 1 : partir d'un problème coûteux, pas de « faire de l'IA »

Sur le terrain, plusieurs dirigeants nous disent la même chose, sous différentes formes : « notre personne clé part dans un an et personne ne sait faire ce qu'elle fait ». Personne ne dit « je veux de l'IA ». On parle de continuité, d'arrêts, de temps perdu à former.

Remi Duquette, vice-président Innovation et IA industrielle chez Maya HTT, disait la même chose lors d'un webinaire d'AI4Manufacturing (traduction) : « Commencez par vos défis d'affaires. Avant de sortir la baguette magique du modèle de langage, faites la liste de vos petits et grands problèmes. Ne regardez pas l'IA, elle vient plus loin dans le flux. » (webinaire)

Daryl Edwards, fondateur d'Agent Impact, lors d'un autre webinaire d'AI4Manufacturing, le résumait ainsi (traduction) : « Je ne me réveille pas en me disant qu'il me faut de l'IA. Je me réveille en me disant qu'il me faut plus de débit, de meilleures livraisons à temps. » (webinaire)

Des problèmes de départ typiques :

• une question que les nouveaux posent sans cesse aux mêmes experts;
• un arrêt de machine qui revient et que seuls un ou deux techniciens savent régler;
• un quart de nuit ou de fin de semaine où personne ne peut répondre;
• un savoir qui n'est écrit nulle part et qui part à la retraite.

Un test simple : que coûte une demi-journée d'arrêt, ou une semaine de formation d'un nouvel opérateur ? Faites le calcul avec vos propres chiffres. Si le problème ne coûte rien, ce n'est pas le bon premier projet.

Étape 2 : choisir un seul procédé

Un procédé, une ligne, un jeu de documents. Pas l'usine au complet.

Un premier cas courant : un assistant qui répond aux questions de première ligne à partir des procédures de l'usine (réglage, recette, dépannage). Il épaule l'opérateur. Il ne décide pas et ne commande aucune machine.

Voir nos cas d'usage pour réduire les temps d'arrêt, former un nouvel opérateur plus vite ou garder le savoir avant un départ à la retraite.

Étape 3 : regarder ce qui existe déjà comme savoir

Avant de parler d'outil, faites l'inventaire. Manuels de fournisseurs, fiches de réglage, feuilles de recettes, rapports d'incident, notes de fin de quart, courriels, photos, vidéos, notes manuscrites d'un ancien.

Deux choses reviennent souvent sur le terrain :

• « On n'a pas de documentation propre. » Ce n'est pas un obstacle, c'est un point de départ. Des notes, des enregistrements audio ou des vidéos d'un expert peuvent servir de base.
• La documentation officielle décrit l'usine telle qu'elle était. Les rapports d'incident et de quart décrivent l'usine telle qu'elle est. Les deux comptent.

Prévoyez aussi de décider, avec votre expert maison, quel document l'emporte quand deux sources se contredisent. En général, ce qu'écrit votre expert doit primer sur le manuel générique du fournisseur.

Étape 4 : un petit prototype sur 10 à 15 documents réels

Ne montez pas un grand projet de données. Prenez 10 à 15 documents réels d'un seul procédé, ceux que vos gens consultent vraiment, et construisez un prototype dessus.

Ce petit essai vous apprendra plus qu'une présentation de six mois :

• les réponses viennent-elles des bonnes sources ?
• l'outil dit-il « je ne sais pas » quand il ne sait pas ?
• les opérateurs comprennent-ils la réponse ?

Deux détails qui changent tout à l'usage : chaque réponse doit montrer la page du document d'où elle vient, pour que l'opérateur puisse vérifier; et l'outil doit pouvoir poser une question de clarification (quel code d'erreur, quel matériau) avant de proposer une cause, comme le ferait un bon technicien.

Et n'attendez pas des données parfaites. Remi Duquette, encore lui, lors d'un webinaire d'AI4Manufacturing (traduction) : « Remonter dix ans de données pour tout nettoyer serait à mon avis une perte de temps. Regardez plutôt vers l'avant : quels processus mettre en place pour avoir des données propres à partir de maintenant. » (webinaire)

Étape 5 : un champion sur le plancher

C'est le point qui revient le plus souvent dans nos échanges avec des usines. Un ingénieur, un responsable d'usine ou un chef d'équipe vit le problème tous les jours, fournit les documents, valide les réponses. Il n'a pas besoin d'être technique.

Remi Duquette, lors d'un webinaire d'AI4Manufacturing (traduction) : « Il vous faut un champion interne, quelqu'un qui tient à porter la production et l'adoption une fois qu'on a quitté les lieux. Souvent une personne jeune et motivée, qui n'a pas besoin d'être très technique. » (webinaire)

Sans champion, les projets s'arrêtent souvent après la démonstration.

Parlez aussi aux opérateurs dès le début. Plusieurs craignent d'être remplacés. L'outil est là pour les épauler, pas pour décider à leur place. S'ils n'en veulent pas, ils trouveront comment le laisser tomber.

Étape 6 : mesurer l'usage, pas la démo

Définissez avant de commencer ce que « ça marche » veut dire, en termes très concrets. Par exemple :

1. Trois cas de dépannage connus, que l'assistant traite correctement.
2. Une opératrice ou un opérateur obtient une réponse en une trentaine de secondes, sur son téléphone, au poste.
3. Sur quelques semaines, on note combien de questions sont posées, par qui, et à quel quart.
4. On note aussi les questions restées sans bonne réponse.

Attention : trois cas de test ne prouvent pas un taux de précision en production. Ils disent si l'idée tient la route. L'usage réel, lui, dit si l'outil est utile.

Et traduisez le résultat en dollars : un pourcentage de gain ne dit rien s'il ne touche pas un vrai coût.

Quatre pièges à éviter

Commencer par les TI. Les TI sont rarement l'acheteur, mais souvent celui qui bloque. Commencer par eux oblige à défendre une architecture avant d'avoir prouvé la valeur. Commencez par la production, mais prévenez les TI tôt : les accès aux fichiers et aux permissions retardent souvent la collecte de documents.

La démonstration trop tôt. Une démo impressionnante avec des documents génériques ne dit rien sur votre usine. Testez sur vos documents, avec vos gens.

Le perfectionnisme des données. Un tableur contient parfois des valeurs absurdes (des zéros, des valeurs impossibles), et l'outil les répète fidèlement. Faites un audit de départ, mais sur le petit lot du prototype, pas sur tout l'historique.

Oublier qui tient la base à jour. Qui ajoute le nouveau réglage, qui retire la procédure périmée, six mois après le prototype ? Décidez-le avant la fin de l'essai. Sans rôle clair, la base de connaissances vieillit et les gens cessent de s'y fier.

Checklist : avant de lancer votre premier projet

1. Le problème est nommé et son coût est estimé avec vos chiffres.
2. Un seul procédé est choisi.
3. Vos 10 à 15 documents de départ sont identifiés.
4. Un champion sur le plancher est désigné.
5. Les critères de réussite sont écrits avant de commencer.
6. Un responsable de la mise à jour du savoir est nommé.

Par où on commence chez Manufacturia

Chez Manufacturia, on propose justement de commencer petit : un cas ciblé, choisi avec vous, mis entre les mains de vos opérateurs sur une vraie période de test. Voir la section « Démarrer » de la page Services et nos cas d'usage. Si vous voulez en parler, réservez 15 minutes avec nous.

Questions fréquentes

Faut-il de l'IA dans notre usine, même si on est une petite PME ? La taille compte moins que le problème. Erin Grant, d'Impact AI, disait lors d'un webinaire d'AI4Manufacturing que ce qui compte, c'est le problème et si l'outil convient à l'application, pas le nombre d'employés. Si le problème ne coûte pas cher, attendez.

Combien de temps pour un premier essai ? Ça dépend de la disponibilité de vos documents et de vos gens. Un prototype sur un seul procédé se prépare en quelques semaines, suivi d'une période de test avec les opérateurs. Ne visez pas un déploiement complet d'emblée.

Est-ce qu'on a besoin d'une documentation parfaite ? Non. Des notes, des rapports d'incident, des enregistrements audio ou des vidéos peuvent servir de point de départ. L'important est de savoir quel document prime quand deux sources se contredisent.