Vos données sont-elles prêtes pour l’IA ?

Les entreprises manufacturières accumulent des données depuis des années.

Leur ERP conserve l’historique des commandes, des stocks et des opérations. Les équipements génèrent des mesures en continu. Les équipes de maintenance consignent les arrêts et les interventions. Les services de qualité documentent les défauts, tandis que les superviseurs produisent leurs propres rapports et tableaux de suivi.

Devant cette abondance d’information, une conclusion semble naturelle : l’entreprise doit certainement posséder tout ce qu’il faut pour développer une solution d’intelligence artificielle.

La réalité est plus nuancée.

La vraie question n’est pas seulement :

Avons-nous des données?

Elle est plutôt :

Nos données racontent-elles réellement ce qui se passe dans nos opérations?

Des données peuvent être suffisamment structurées pour soutenir les opérations courantes sans être assez précises, cohérentes ou contextualisées pour entraîner un modèle. Elles peuvent indiquer qu’un événement s’est produit sans expliquer pourquoi. Elles peuvent être réparties entre plusieurs systèmes ou documentées différemment selon les équipes. Certaines connaissances essentielles peuvent même ne jamais être consignées parce qu’elles demeurent dans la tête des employés expérimentés.

La question n’est donc pas seulement de savoir si votre entreprise possède des données. Il faut plutôt déterminer si elle possède les bonnes données, dans un format adapté et avec un niveau de contexte qui permettent de répondre au problème visé.

Avoir des données ne signifie pas avoir un cas d’usage

Avant d’évaluer la qualité d’un ensemble de données, il faut savoir ce que l’on cherche à accomplir.

Une entreprise peut posséder vingt ans d’historique sur ses clients, ses commandes ou ses équipements. Cet historique ne devient pas automatiquement utile pour l’IA simplement parce qu’il est volumineux.

Pour déterminer sa valeur, il faut d’abord formuler une question précise.

Cherche-t-on à prévoir un arrêt? À détecter un défaut? À recommander une intervention? À réduire les pertes de matière? À mieux planifier une opération? À faciliter la recherche dans la documentation technique?

Sans question définie, l’analyse ressemble à la recherche d’une aiguille dont on ne connaît ni la forme ni l’emplacement. Le volume de données augmente alors l’espace à explorer, mais il n’indique pas ce qu’il faudrait y trouver.

Cette distinction est importante, car la même donnée peut être utile pour un objectif et insuffisante pour un autre.

Un historique de production pourrait permettre de calculer le nombre d’arrêts par mois sans pour autant permettre d’en prédire les causes. Un registre de défauts pourrait répondre aux besoins de traçabilité sans contenir les détails nécessaires à un système de reconnaissance visuelle.

La première étape pour un projet d’IA consiste donc à relier les données à un problème d’affaires :

Quelle décision, prédiction, détection ou recommandation souhaitons-nous améliorer?

C’est seulement à partir de cette question qu’il devient possible de déterminer les informations nécessaires.

Des données conçues pour un ERP ne sont pas nécessairement conçues pour l’IA

Les systèmes de gestion sont développés pour répondre à des objectifs précis.

Un ERP doit notamment permettre d’enregistrer des transactions, de suivre les commandes, de gérer les stocks et de coordonner les opérations. Il n’a pas nécessairement été conçu pour expliquer en détail les causes d’une panne ou les conditions exactes dans lesquelles un défaut est apparu.

Une donnée peut donc être parfaitement valide pour son usage initial, mais insuffisante pour un projet d’IA.

Prenons l’exemple d’un code d’arrêt. Pour les besoins d’un rapport mensuel, il peut être suffisant de savoir qu’un équipement s’est arrêté pendant 45 minutes en raison d’un « problème mécanique ». Pour développer un assistant de diagnostic, cette catégorie est probablement trop générale.

Pour développer un assistant de diagnostic, le système aurait plutôt besoin de relier plusieurs informations : les symptômes observés, les mesures prises avant l’arrêt, les paramètres de la machine, les conditions de production, le composant en cause, la cause confirmée, l’intervention réalisée et le résultat obtenu.

Si ces informations n’ont jamais été recueillies, elles ne peuvent pas être reconstituées automatiquement à partir de la seule durée de l’arrêt.

L’intelligence artificielle peut repérer des relations, reconnaître des configurations et produire des recommandations à partir des données disponibles. Elle ne peut toutefois pas déduire de façon fiable une cause qui n’a jamais été observée ni documentée.

La cohérence de la saisie est un enjeu déterminant

Les données manufacturières sont créées par des systèmes, mais aussi par des personnes. Leur qualité dépend donc des pratiques quotidiennes de documentation.

Dans une même entreprise, les défauts observés peuvent être consignés de façon détaillée par certaines équipes, alors que d’autres les regroupent dans une catégorie plus générale. Un quart de travail peut documenter le type de défaut, la machine concernée et l’action corrective, tandis qu’un autre utilise systématiquement le premier choix offert dans le formulaire afin de terminer la saisie plus rapidement.

Les données existent dans les deux cas, mais elles ne possèdent ni la même précision ni la même valeur analytique.

Ces écarts peuvent être difficiles à détecter dans les rapports habituels. Une catégorie générique peut paraître valide dans une base de données, même si elle regroupe en réalité plusieurs phénomènes différents. Le problème devient visible seulement lorsqu’on essaie d’utiliser ces données pour entraîner un modèle.

Le système peut alors apprendre les habitudes de saisie des équipes plutôt que les caractéristiques réelles du procédé. Il peut également produire des résultats différents selon le quart de travail, l’usine ou la personne qui a documenté l’événement.

Avant de lancer un projet, il faut donc examiner non seulement les champs présents dans la base de données, mais aussi la manière dont ils sont remplis :

• Les catégories sont-elles comprises de la même manière par tous?
• Certains champs sont-ils régulièrement laissés vides?
• Des valeurs génériques sont-elles utilisées par défaut?
• Les pratiques varient-elles selon les quarts, les sites ou les équipes?
• Les informations sont-elles saisies au moment de l’événement ou plusieurs heures plus tard?
• Existe-t-il des vérifications permettant de repérer les incohérences?

La qualité d’une donnée ne dépend pas uniquement de sa présence. Elle dépend aussi de la constance avec laquelle elle représente la réalité.

Une panne sans cause documentée apprend peu au modèle

Les données d’arrêt de machines illustrent bien la différence entre un historique opérationnel et un actif exploitable pour l’IA.

Une entreprise peut connaître avec précision l’heure du début de chaque arrêt, sa durée et l’équipement concerné. Ces informations permettent de mesurer la disponibilité des machines et de mesurer le taux de rendement global. Elles ne suffisent toutefois pas nécessairement pour développer une solution de diagnostic ou de maintenance prédictive.

Pour qu’un modèle puisse établir des liens utiles, l’événement doit être associé à un contexte et à un résultat.

Idéalement, chaque incident devrait permettre de relier plusieurs éléments :

1. les conditions qui précèdent l’événement;
2. le symptôme ou le défaut observé;
3. la cause déterminée;
4. l’intervention effectuée;
5. le retour ou non à un fonctionnement normal.

Si la base de données indique seulement qu’une machine s’est arrêtée, le modèle peut apprendre à reconnaître certains signaux précédant un arrêt. Il lui sera beaucoup plus difficile de distinguer les différentes causes possibles ou de recommander une action appropriée.

La documentation de l’intervention est tout aussi importante. Deux arrêts peuvent présenter des symptômes semblables tout en nécessitant des correctifs différents. Sans connaître l’action réalisée et son résultat, il est impossible de déterminer quelle intervention a réellement résolu le problème.

L’enjeu n’est donc pas d’accumuler toujours plus de données d’arrêt. Il consiste à mieux documenter la chaîne complète qui va de l’observation à la résolution.

Pour approfondir le sujet, lisez l’article Arrêts non planifiés : le coût caché du temps de diagnostic.

Le contexte transforme une donnée en information utile

Une image, une mesure ou une note ne prend tout son sens que lorsqu’elle est replacée dans son contexte.

Une photographie d’une pièce défectueuse peut sembler très utile pour développer un système d’inspection. Mais que représente-t-elle exactement? Le défaut a-t-il été confirmé par un spécialiste? La pièce a-t-elle été rejetée? S’agit-il d’une variation acceptable? Quels étaient le matériau, l’éclairage, le lot, la machine et les paramètres de production?

Sans ces renseignements, une collection d’images peut être difficile à interpréter. Certaines images pourraient représenter le même défaut sous des conditions différentes. D’autres pourraient montrer plusieurs défauts simultanément ou contenir des variations qui ne compromettent pas la conformité de la pièce.

Le même principe s’applique aux données de machines. Une variation de température peut indiquer une anomalie dans un contexte et être parfaitement normale dans un autre. Pour l’interpréter, il faut connaître notamment le produit fabriqué, l’étape du cycle, la vitesse de production et les réglages appliqués.

Le contexte permet de comprendre ce qui s’est produit, dans quelles conditions l’événement est survenu et quel a été le verdict ou le résultat. Plus ces éléments sont documentés avec précision, plus les données peuvent soutenir une analyse pertinente.

L’exemple Bridgestone : des données reliées à un problème précis

Le projet mené par Bridgestone Canada à son usine de Joliette illustre pourquoi les données doivent être reliées à un problème opérationnel précis pour devenir réellement utiles.

L’entreprise cherchait à réduire des arrêts de production causés par des joints imparfaits entre les couches de caoutchouc durant l’assemblage des pneus. Le défi était complexe : les arrêts survenaient fréquemment, la matière première variait selon des conditions comme la température ou l’humidité, et les paramètres de fabrication à ajuster étaient nombreux.

Dans ce contexte, l’historique de production ne suffisait pas à lui seul. Pour produire des recommandations utiles, les données devaient permettre de comprendre les liens entre les conditions de production, les paramètres de fabrication, les variations de la matière et la qualité des joints obtenus.

L’exploitation de plus d’un an de données historiques a permis d’analyser ces relations et d’identifier les variables influençant la qualité. Des modèles prédictifs et des analyses de séries temporelles ont ensuite servi à concevoir un système de recommandation capable de guider les opérateurs dans leurs ajustements.

Ce cas montre que les données deviennent exploitables lorsqu’elles ne se limitent pas à constater qu’un arrêt ou un défaut s’est produit. Elles doivent aussi aider à comprendre pourquoi il s’est produit, quels facteurs l’influencent et comment les équipes peuvent agir pour le prévenir.

La qualité peut compter davantage que la quantité

Pendant longtemps, les projets d’IA ont souvent été associés à la nécessité d’accumuler de très grandes quantités de données. Cette perception peut décourager certaines entreprises manufacturières, particulièrement lorsque les défauts recherchés sont rares ou que les événements critiques se produisent peu fréquemment.

Les progrès technologiques permettent aujourd’hui d’envisager certains projets avec des ensembles de données plus limités. Cela ne signifie pas qu’un petit nombre d’exemples suffit toujours. Les besoins varient selon le problème, la diversité des conditions, la précision recherchée et la méthode utilisée.

Cela signifie plutôt qu’un ensemble plus restreint de données correctement documentées peut parfois être plus utile qu’une grande quantité d’exemples ambigus.

Cent images dont le contexte, le défaut et le verdict ont été validés par un expert peuvent fournir une base plus solide que des milliers d’images sans étiquette fiable. De la même façon, un historique de maintenance plus court, mais reliant clairement chaque symptôme à sa cause et à sa résolution, peut être préférable à plusieurs années de notes incomplètes.

Le contexte est important : il ne suffit pas de fournir des images ou des événements au système; il faut aussi documenter ce qu’ils représentent et les conditions dans lesquelles ils ont été observés.

Il faut néanmoins éviter de transformer cette idée en règle universelle. Le volume nécessaire ne peut pas être déterminé avant d’avoir examiné le cas d’usage, la variabilité des données et le niveau de performance attendu.

La bonne question n’est donc pas :

Avons-nous assez de données?

Elle est plutôt :

Avons-nous suffisamment de données représentatives et fiables pour répondre à notre question avec le niveau de confiance requis?

Les fichiers Excel parallèles révèlent souvent des données importantes

Dans plusieurs entreprises, une partie de l’information opérationnelle demeure à l’extérieur des systèmes officiels. Elle se trouve dans des fichiers Excel, des documents locaux, des notes personnelles ou des tableaux créés par les employés pour répondre à des besoins que les outils existants ne couvrent pas complètement.

Ces fichiers peuvent révéler des informations essentielles qui ne se trouvent pas toujours dans les systèmes officiels : des indicateurs réellement utilisés sur le terrain, des étapes manuelles entre deux systèmes, des catégories créées par les équipes, des exceptions que les outils existants ne savent pas gérer ou des décisions qui reposent encore sur l’interprétation d’un employé.

La multiplication des systèmes en silos, des retranscriptions et des fichiers parallèles constitue une réalité courante dans les environnements manufacturiers. Les employés consacrent alors du temps à copier, à corriger ou à réorganiser l’information pour pouvoir accomplir leur travail.

Avant d’envisager de centraliser ou d’éliminer ces fichiers, il faut comprendre pourquoi ils existent. Ils peuvent constituer le symptôme d’un problème d’intégration, mais aussi contenir une partie du contexte nécessaire à un futur projet d’IA.

Ils présentent néanmoins des limites importantes. Leur structure peut varier d’une personne à l’autre. Les versions peuvent se multiplier. Certaines colonnes peuvent être interprétées différemment, et les formules peuvent être modifiées sans traçabilité.

L’objectif n’est donc pas de verser automatiquement tous les fichiers dans un modèle. Il consiste à déterminer quelles informations utiles ils contiennent et comment les intégrer à un processus de données plus cohérent.

Les connaissances non documentées représentent aussi une lacune de données

Toutes les données utiles ne se trouvent pas encore dans une base de données.

Dans de nombreuses usines, les employés expérimentés reconnaissent certains problèmes à partir d’un bruit, d’une vibration, d’une odeur, d’une apparence ou d’une combinaison de signaux difficiles à formaliser. Ils savent quelles vérifications effectuer en premier et quelles interventions ont le plus de chances de fonctionner.

Cette expertise constitue une forme de donnée, même si elle n’est pas encore numérisée.

Lorsqu’une panne est résolue sans que le raisonnement, la cause et l’intervention soient documentés, l’entreprise perd une occasion d’enrichir sa mémoire organisationnelle. Le problème est réglé à court terme, mais l’information demeure inaccessible aux autres employés et à tout futur système d’aide au diagnostic.

Pour préparer les données, il peut donc être nécessaire d’adapter les pratiques de travail. Un technicien pourrait, par exemple, consigner plus systématiquement :

• les symptômes qu’il a observés;
• les hypothèses envisagées;
• les vérifications effectuées;
• la cause confirmée;
• la réparation réalisée;
• le résultat obtenu.

La technologie peut faciliter cette captation au moyen d’un formulaire simplifié, d’une tablette, de photos annotées ou de notes vocales. L’outil choisi importe toutefois moins que la régularité et la qualité de la documentation. Lorsque toute l’expertise demeure « entre les deux oreilles » de quelques personnes, ni les nouveaux employés ni les systèmes d’IA ne peuvent réellement en tirer parti.

L’analytique de données prépare le terrain pour l’IA

L’analytique occupe une place centrale dans l’utilisation de l’IA par les entreprises au Canada. Au deuxième trimestre de 2026, 19,2 % des entreprises canadiennes déclaraient avoir utilisé l’IA pour produire des biens ou fournir des services au cours des 12 mois précédents. Parmi ces entreprises, l’analytique de données était l’application la plus souvent mentionnée, à 36,6 %.

Une autre étude de Statistique Canada montre que les entreprises qui utilisaient déjà l’analytique de données étaient 15 points de pourcentage plus susceptibles d’adopter l’IA que celles qui ne l’utilisaient pas.

Cette association ne démontre pas que l’analytique cause à elle seule l’adoption de l’IA. Elle suggère néanmoins que les compétences, les pratiques et les infrastructures liées aux données constituent des capacités complémentaires importantes.

Autrement dit, préparer les données n’est pas une étape administrative distincte du projet d’IA. C’est une partie intégrante de la capacité de l’entreprise à utiliser cette technologie.

Les organisations qui savent déjà localiser leurs données, vérifier leur qualité, les relier entre elles et les utiliser pour soutenir des décisions possèdent généralement une base plus favorable pour explorer des applications avancées.

Comment évaluer si vos données sont prêtes?

La préparation des données ne se résume pas à un résultat binaire. Une entreprise peut être prête pour un cas d’usage et ne pas l’être pour un autre.

Une évaluation devrait commencer par un échantillon représentatif des données liées au problème. Il est rarement nécessaire d’examiner immédiatement l’ensemble de l’historique. L’objectif initial consiste plutôt à déterminer ce que les données permettent réellement de comprendre.

1. Les données pertinentes existent-elles?

Il faut d’abord vérifier si les variables directement liées au problème sont disponibles.

Pour prévoir une panne, l’entreprise possède-t-elle les mesures antérieures à l’événement? Pour reconnaître un défaut, dispose-t-elle d’images représentatives? Pour recommander une intervention, les causes et les correctifs sont-ils documentés?

Une grande quantité de données périphériques ne compense pas l’absence de l’information essentielle.

2. Les données sont-elles suffisamment complètes?

Certains champs peuvent exister dans le système sans être régulièrement remplis. Il faut mesurer la proportion de valeurs manquantes et déterminer si les omissions sont aléatoires ou liées à certaines équipes, périodes ou situations.

Une donnée manquante lors des événements les plus complexes peut créer un biais important.

3. Sont-elles saisies de manière cohérente?

Les catégories, unités et conventions doivent être examinées. Le même défaut porte-t-il plusieurs noms? Les mesures utilisent-elles toujours la même unité? Les horodatages des différents systèmes peuvent-ils être synchronisés?

Des règles de normalisation peuvent corriger certains écarts, mais elles ne peuvent pas toujours reconstituer le sens perdu.

4. Le contexte est-il préservé?

La donnée doit pouvoir être reliée au produit, au lot, à la machine, au quart de travail, aux paramètres du procédé et, lorsque c’est pertinent, aux conditions environnementales.

Sans cette association, il devient difficile de distinguer une variation normale d’une anomalie.

5. Dispose-t-on d’un résultat de référence?

Pour plusieurs projets, il faut connaître la « bonne réponse » permettant d’évaluer le modèle. Il peut s’agir du verdict d’un inspecteur, de la cause confirmée d’une panne ou du résultat réel d’une intervention.

Si cette référence n’existe pas, il faudra peut-être commencer par la créer.

6. Les données sont-elles accessibles et sécurisées?

Les informations peuvent être réparties entre l’ERP, les machines, les logiciels de maintenance, les fichiers Excel et les systèmes de contrôle. Il faut déterminer si elles peuvent être extraites et réunies sans perturber les opérations ni compromettre la sécurité.

Avant de connecter une solution à un ERP, à un MES ou à des équipements de production, il peut être préférable de travailler dans un environnement séparé, avec un entrepôt de données. Cette approche permet d’explorer le potentiel d’un cas d’usage sans compromettre les opérations courantes.

7. Sont-elles représentatives des conditions réelles?

Les données doivent couvrir la diversité que la solution rencontrera une fois déployée : différents produits, réglages, équipements, quarts de travail, saisons ou conditions d’éclairage.

Un modèle entraîné uniquement sur les situations les plus courantes peut échouer précisément dans les cas rares où son aide serait la plus utile.

Que faire lorsque les données ne sont pas prêtes?

Découvrir que les données sont insuffisantes ne signifie pas nécessairement qu’il faut abandonner le projet. Cette conclusion peut au contraire fournir une feuille de route concrète.

L’entreprise peut commencer par améliorer la collecte autour d’un périmètre limité : une machine, une famille de défauts ou une catégorie de pannes. Les formulaires peuvent être simplifiés afin de favoriser une saisie plus constante. Les catégories peuvent être clarifiées avec les utilisateurs. Certains champs obligatoires peuvent être ajoutés, et les employés peuvent être informés de la manière dont les données seront utilisées.

Il est également possible de réunir un petit groupe d’experts afin de réviser et d’annoter un échantillon. Ce travail permet de vérifier si les informations existantes contiennent suffisamment de valeur pour poursuivre l’exploration.

La préparation des données peut ainsi progresser par étapes :

1. définir le problème et les informations nécessaires;
2. examiner un échantillon des données actuelles;
3. repérer les lacunes et les incohérences;
4. améliorer la méthode de documentation;
5. recueillir de nouvelles données de manière régulière;
6. vérifier leur qualité avant de développer le modèle.

Cette démarche crée de la valeur même si le projet d’IA n’est pas lancé immédiatement. Des données mieux structurées peuvent déjà faciliter l’analyse des opérations, le suivi de la qualité, la formation et la prise de décision.

À lire aussi

• Par où commencer avec l’IA dans une entreprise manufacturière? Pour choisir un premier cas d’usage réaliste, mesurable et aligné sur vos objectifs d’affaires.
• L’IA n’est pas toujours la meilleure solution à un problème manufacturier Pour comparer l’IA avec des approches plus simples comme les règles, l’automatisation ou l’intégration des systèmes.
• Les arrêts non planifiés

Conclusion

Préparer les données, c’est préparer le projet

Les entreprises manufacturières n’ont pas nécessairement besoin d’attendre d’avoir une base de données parfaite pour explorer l’IA. Elles doivent toutefois connaître les limites des données dont elles disposent et éviter de confondre quantité, qualité et pertinence.

Un historique volumineux peut constituer un actif important, mais seulement s’il permet de relier les événements à leur contexte, à leurs causes et à leurs résultats. Les données doivent représenter les opérations de manière suffisamment cohérente pour que les relations observées soient fiables.

La préparation des données commence donc bien avant l’entraînement d’un modèle. Elle commence dans la manière de documenter une panne, de classer un défaut, de relier une intervention à son résultat et de préserver l’expertise des employés.

Avant de demander ce que l’IA peut découvrir dans vos données, posez-vous une question plus fondamentale : Nos données racontent-elles réellement ce qui se passe dans nos opérations?

Lorsque la réponse est incertaine, une évaluation ciblée peut aider à déterminer les informations déjà exploitables, les lacunes à combler et les pratiques à mettre en place.

Les experts en IA de Luqia peuvent vous accompagner pour évaluer la qualité et la pertinence de vos données au regard d’un besoin manufacturier précis, puis déterminer les prochaines étapes réalistes de votre projet.

Sources statistiques

Statistique Canada, « Analyse de l’utilisation de l’intelligence artificielle par les entreprises au Canada, deuxième trimestre de 2026 », 11 juin 2026 :
https://www150.statcan.gc.ca/n1/pub/11-621-m/11-621-m2026010-fra.htm

Statistique Canada, « Adoption de l’intelligence artificielle et productivité dans les entreprises canadiennes », 22 avril 2026 :
https://www150.statcan.gc.ca/n1/pub/36-28-0001/2026004/article/00002-fra.htm