Comment utiliser l’apprentissage automatique quand une entreprise possède beaucoup de données mais peu d’expertise ?

Une entreprise peut accumuler des années de transactions, de dossiers clients et de données opérationnelles sans savoir comment les transformer en décisions utiles. L’apprentissage automatique, ou machine learning, permet de rechercher des régularités dans ces informations pour produire des prévisions, classer des documents ou détecter des situations inhabituelles. Mais posséder beaucoup de données ne garantit ni leur qualité ni la pertinence d’un modèle prédictif.

Pour une PME canadienne disposant de peu d’expertise technique, la démarche la plus réaliste consiste à identifier une décision répétitive, vérifier les données nécessaires, puis tester une solution limitée avant d’envisager son automatisation. Selon Statistique Canada, 19,2 % des entreprises interrogées au deuxième trimestre de 2026 déclaraient avoir utilisé l’intelligence artificielle pour produire des biens ou fournir des services au cours des douze mois précédents. Ce chiffre concerne l’IA au sens large et ne prouve pas la rentabilité des projets réalisés.

Le véritable enjeu n’est donc pas de déployer rapidement un algorithme, mais de construire un processus de décision mesurable, maîtrisable et compatible avec les obligations de protection des renseignements personnels.

Pourquoi certains problèmes d’entreprise se prêtent-ils mieux que d’autres à l’apprentissage automatique ?

L’apprentissage automatique convient surtout aux problèmes répétitifs pour lesquels une entreprise possède des exemples historiques, un résultat mesurable et une certaine tolérance aux erreurs. La prévision de la demande, le classement de documents et la détection d’anomalies constituent des pistes possibles. En revanche, une décision exceptionnelle, mal documentée ou entièrement déterminée par des règles simples justifie rarement un modèle prédictif.

Avant de lancer un projet, le responsable métier peut examiner cinq critères :

• Données historiques : les observations couvrent-elles suffisamment de situations pertinentes, avec des résultats connus et fiables ?
• Stabilité du processus : les mécanismes qui relient les informations aux résultats restent-ils relativement constants ?
• Résultat mesurable : existe-t-il une façon de comparer la prédiction à ce qui s’est réellement produit ?
• Tolérance aux erreurs : une mauvaise prédiction peut-elle être corrigée sans conséquence disproportionnée ?
• Coût de la méthode actuelle : le temps humain économisé et les erreurs évitées justifient-ils les coûts de développement, de contrôle et de maintenance ?

La différence entre automatiser une règle et apprendre une relation est fondamentale. Si un document doit être dirigé vers un service selon un code déjà présent dans l’ERP, une règle informatique suffit généralement. Un modèle devient plus intéressant lorsque le classement dépend d’indices multiples, variables et difficiles à formaliser explicitement.

Parmi les entreprises canadiennes déclarant utiliser l’IA, 36,6 % mentionnaient l’analyse de données et 34,5 % l’analyse de texte parmi leurs applications. Ces proportions décrivent des usages déclarés, sans établir leur performance économique.

Pour une PME qui travaille entre le Québec et d’autres provinces, une prévision par famille de produits peut être plus accessible qu’un système national intégrant immédiatement toutes les particularités commerciales, linguistiques et opérationnelles. Cette approche réduit les différences que le modèle doit apprendre simultanément.

Trois situations invitent toutefois à différer le projet : un processus récemment transformé, des décisions humaines dont les motifs ne sont pas enregistrés, ou des données recueillies uniquement pour satisfaire une obligation administrative. Dans ces cas, documenter le processus et améliorer la collecte constituent souvent les premiers investissements utiles.

Une fois le problème sélectionné, la question suivante n’est pas encore celle de l’algorithme : il faut vérifier que les informations disponibles décrivent réellement la situation que l’entreprise souhaite prédire.

Comment préparer des données imparfaites avant d’entraîner un modèle prédictif ?

La préparation des données consiste à vérifier leur fiabilité, corriger les incohérences utiles au projet et définir précisément le résultat à prédire. Une entreprise doit notamment rapprocher ses sources, identifier les informations manquantes et éviter d’utiliser des variables qui ne seront pas disponibles lors des futures prédictions. La qualité des données compte davantage que leur volume brut.

Dans un premier projet, cette préparation peut représenter une charge de travail considérable. Sa durée dépend toutefois de l’état des systèmes, des accès, de la documentation et du problème étudié : aucun pourcentage universel ne permet de la prévoir.

Une démarche opérationnelle peut suivre quatre étapes :

1. Inventorier les sources. Identifier les champs disponibles dans le CRM, l’ERP, les bases transactionnelles et les fichiers manuels, ainsi que leurs responsables et périodes de couverture.
2. Auditer la qualité. Mesurer les doublons, valeurs absentes, formats incompatibles, erreurs de saisie et écarts entre systèmes.
3. Définir la variable cible. Préciser exactement ce que le modèle doit prédire, à quelle échéance et à partir de quelles informations.
4. Préparer l’évaluation. Séparer les données utilisées pour construire le modèle de celles servant à mesurer sa performance sur des observations non apprises.

Tous les défauts n’ont pas le même effet. Une erreur systématique de codification peut orienter continuellement le modèle dans une mauvaise direction. Des valeurs manquantes occasionnelles peuvent être gérées selon leur fréquence et leur signification. Un biais de collecte est parfois plus difficile à découvrir : une base composée uniquement de clients ayant acheté ne représente pas nécessairement les personnes ayant abandonné leur commande.

La quantité de données nécessaire dépend de la complexité du problème et de la diversité des situations. Un classement simple peut être évalué avec un corpus modeste, mais des événements rares ou de nombreuses catégories exigent généralement davantage d’exemples pertinents. Il est préférable de vérifier la représentation de chaque catégorie plutôt que de fixer arbitrairement un nombre total d’enregistrements.

Un risque particulièrement trompeur est la fuite de données. Imaginons une entreprise qui souhaite prévoir les retards de livraison à l’expédition. Si le modèle utilise un champ renseigné après la livraison, ses résultats historiques peuvent sembler excellents. Pourtant, ce champ n’existera pas au moment où la prédiction doit être produite.

Il faut également respecter la chronologie lorsqu’elle détermine l’usage réel. Pour prévoir les ventes futures, une évaluation fondée sur une période ultérieure à celle de l’entraînement est généralement plus représentative qu’une répartition aléatoire mélangeant passé et futur.

Ce diagnostic permet aussi de mesurer l’effort technique nécessaire, un élément décisif pour choisir entre une solution existante et un développement propre à l’entreprise.

Modèle sur mesure ou outil prêt à l’emploi : que choisir pour un premier projet d’IA ?

Pour un premier projet d’intelligence artificielle, un outil prêt à l’emploi est généralement plus adapté lorsque le problème ressemble à un usage standard et que l’entreprise manque de ressources techniques. Un modèle sur mesure devient pertinent si les contraintes métiers exigent une personnalisation importante et si les gains attendus couvrent durablement les coûts de développement, d’intégration et de maintenance.

Le choix peut être structuré autour de trois questions : le besoin est-il standardisable, le processus est-il suffisamment stable et l’organisation peut-elle assumer la responsabilité technique du système ?

Le tableau suivant compare les conséquences pratiques des deux approches.

L’achat d’un outil n’élimine pas la nécessité de comprendre ses décisions. Une solution commerciale peut échouer si les données d’entrée sont différentes de celles pour lesquelles elle a été conçue. Inversement, un système personnalisé peut produire d’excellents résultats expérimentaux sans que l’entreprise dispose des moyens de l’exploiter durablement.

Au Canada, la sélection du fournisseur comporte également une dimension juridique. Les données peuvent être hébergées ou traitées hors du pays, et la localisation d’un serveur ne suffit pas à déterminer les obligations applicables. Le secteur, la province, la nature des renseignements et les modalités de communication doivent être examinés.

Au Québec, la Loi 25 a notamment introduit des exigences concernant l’évaluation des facteurs relatifs à la vie privée avant la communication de renseignements personnels hors Québec, ainsi que des conditions relatives à la protection adéquate et à l’entente écrite. Les principaux changements apportés par la Loi 25 selon la Commission d’accès à l’information permettent d’identifier ces obligations. Un transfert hors Québec n’est pas interdit de manière générale, mais doit respecter le cadre applicable.

Pour les activités commerciales relevant du régime fédéral, la Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE) peut également s’appliquer. Son articulation avec les lois provinciales exige une analyse adaptée à l’organisation.

Une trajectoire hybride consiste à expérimenter un outil existant sur des données appropriées et un processus non critique, puis à documenter les limitations réelles. Si des écarts persistants justifient une solution personnalisée, la décision pourra reposer sur des résultats mesurés plutôt que sur une préférence technologique.

Quelle que soit la solution retenue, ses performances moyennes ne suffisent pas à établir sa fiabilité : il reste à comprendre sur quels exemples elle échoue et quelles conséquences ces erreurs peuvent entraîner.

Quels biais peuvent rendre un modèle fiable en apparence mais dangereux en pratique ?

Un modèle peut afficher une bonne précision globale tout en reproduisant des erreurs historiques, en défavorisant certaines catégories sous-représentées ou en amplifiant ses propres décisions. Ces biais apparaissent lorsque les données ne représentent pas correctement les situations futures ou lorsque les résultats passés reflètent des pratiques contestables. La fiabilité exige donc une évaluation détaillée, au-delà d’un score moyen.

Imaginons un système de priorisation des demandes commerciales entraîné sur les décisions antérieures d’une équipe. Si certains secteurs géographiques recevaient historiquement moins d’attention, le modèle pourrait apprendre à leur attribuer des priorités plus faibles. Une bonne concordance avec les décisions passées ne démontrerait pas que ces décisions étaient justifiées.

Trois mécanismes doivent être distingués :

• Biais statistique : une méthode ou un modèle produit des estimations systématiquement décalées par rapport au résultat recherché.
• Biais de sélection : les données d’entraînement ne représentent pas suffisamment certains clients, régions, produits ou situations.
• Boucle de rétroaction : les décisions du modèle modifient les données qui serviront ensuite à son amélioration, avec un risque de renforcement des erreurs.

La précision globale peut masquer ces problèmes. Dans un scénario hypothétique, un modèle de tri pourrait bien classer la majorité des documents tout en commettant fréquemment des erreurs sur les dossiers rédigés dans un format moins représenté. Il serait imprudent de juger le système uniquement à partir de sa moyenne générale.

Une évaluation utile compare la performance par catégories pertinentes : langues, régions, types de documents, familles de produits ou segments de clientèle, lorsque cette segmentation est appropriée et licite. Les faux positifs et les faux négatifs doivent aussi être distingués, car leur coût métier peut être très différent.

Les recommandations du NIST sur la mesure des risques des systèmes d’IA préconisent notamment de définir des métriques adaptées à l’usage, des limites de performance acceptables et des mécanismes de correction. Ce cadre méthodologique américain est pertinent pour l’évaluation technique, sans constituer une obligation juridique canadienne.

Au Québec, des règles particulières s’appliquent lorsqu’une personne fait l’objet d’une décision fondée exclusivement sur un traitement automatisé de renseignements personnels. Elles comprennent notamment une obligation d’information et des possibilités d’intervention ou de révision selon le cadre applicable. Elles ne doivent pas être étendues automatiquement à toute décision simplement assistée par un algorithme.

Au niveau fédéral, le projet de loi C-27 déposé en 2022 prévoyait une Loi sur l’intelligence artificielle et les données. Il n’a pas achevé son parcours législatif durant la 44e législature et ne constitue donc pas, en tant que tel, une loi en vigueur.

Une entreprise qui achète une solution doit demander au fournisseur les catégories utilisées pour les tests, les principales limites connues, la documentation des erreurs et les mécanismes permettant une intervention humaine.

Cette vérification ne se limite pas au lancement : même un modèle correctement évalué peut perdre progressivement sa pertinence lorsque les pratiques et les données évoluent.

Comment améliorer un modèle qui perd en précision après plusieurs mois ?

Lorsqu’un modèle perd en précision, il faut d’abord déterminer si les données reçues ont changé ou si les relations qu’il avait apprises ne sont plus valables. La correction peut passer par un ajustement des données, une modification des variables, un réentraînement contrôlé ou le retour temporaire à une méthode de référence. Réentraîner automatiquement n’est pas toujours la bonne réponse.

Un modèle de prévision des ventes peut devenir moins fiable après une modification de gamme, un changement de clientèle ou une transformation des pratiques commerciales. Cette perte de performance ne correspond pas nécessairement à un défaut logiciel : le système continue parfois de fonctionner exactement comme prévu, mais dans un environnement différent de celui de son apprentissage.

Il faut distinguer deux situations :

• Dérive des données : la distribution des informations d’entrée change. Par exemple, l’entreprise dessert désormais une clientèle dont les comportements diffèrent de ceux du jeu d’entraînement.
• Dérive du concept : la relation entre les informations d’entrée et le résultat attendu évolue. Un indicateur autrefois fortement associé à une commande peut perdre son pouvoir prédictif.

Le diagnostic commence par une comparaison entre les données actuelles, les données historiques et les résultats effectivement observés. Si les résultats métier arrivent avec retard, les variations de distribution peuvent servir de signal d’alerte, mais elles ne démontrent pas à elles seules une baisse de précision.

Les contrôles doivent porter sur plusieurs dimensions : performances globales, erreurs par catégorie, fréquence des interventions humaines, disponibilité des variables et changements dans la collecte. Les seuils d’alerte dépendent du risque métier et ne peuvent pas être universels.

Le cadre de mesure des risques et des performances des systèmes d’IA du NIST recommande notamment d’évaluer les systèmes avant et après leur déploiement, de documenter les limites acceptables et de surveiller les écarts de performance.

Pour une entreprise sans équipe spécialisée, le contrat de maintenance devrait préciser qui surveille les indicateurs, à quelle fréquence, dans quelles circonstances un réentraînement est envisagé et comment une version précédente peut être restaurée.

La prudence est particulièrement importante lorsque les décisions du modèle influencent ses futures données d’entraînement. Un système qui recommande systématiquement certains produits peut réduire la visibilité des autres. Réapprendre uniquement sur les ventes observées après ces recommandations risque alors de renforcer ce comportement sans démontrer qu’il répond à la demande réelle.

Un nouveau modèle doit donc être comparé à la version utilisée auparavant et à une méthode métier simple, sur un jeu d’évaluation approprié, avant son remplacement en production.

Cette maintenance technique doit rester liée à une autre exigence permanente : protéger les renseignements exploités, notamment lorsque leur combinaison permet de révéler plus d’informations que chaque donnée considérée séparément.

Pourquoi des informations ordinaires peuvent-elles devenir sensibles une fois regroupées ?

Des informations apparemment anodines peuvent devenir identifiantes ou sensibles lorsqu’elles sont combinées. Un code postal, une tranche d’âge et un historique d’achats ne désignent pas nécessairement une personne isolément, mais leur recoupement peut permettre de la reconnaître ou de déduire des caractéristiques privées. L’apprentissage automatique accentue ce risque lorsqu’il produit de nouvelles inférences à partir de données ordinaires.

La sensibilité d’un jeu de données ne dépend donc pas uniquement des champs qu’il contient individuellement. Elle dépend aussi des possibilités de rapprochement, des sources auxiliaires accessibles et des caractéristiques que l’entreprise cherche à prédire.

Un modèle peut, par exemple, apprendre des associations entre comportements de consommation et situations personnelles. Ces prédictions peuvent être incertaines ou erronées, mais leur utilisation peut néanmoins créer des risques pour les personnes concernées.

Avant d’exploiter ces données, une organisation doit déterminer si les personnes restent identifiables directement ou indirectement. Retirer les noms et les adresses électroniques ne suffit pas nécessairement à rendre un ensemble anonyme. La pseudonymisation réduit certains risques, mais les possibilités de rapprochement peuvent subsister.

Quatre mesures sont particulièrement utiles :

• Minimiser la collecte : conserver uniquement les variables justifiées par le cas d’usage et les finalités autorisées.
• Réduire la précision : privilégier des catégories ou des agrégations lorsque le détail individuel n’est pas nécessaire.
• Cloisonner les accès : limiter la consultation des données identifiantes aux personnes qui en ont réellement besoin.
• Contrôler les partages : examiner les ensembles transmis aux fournisseurs, leurs possibilités de réutilisation et les conditions de conservation.

Au Québec, la Loi 25 prévoit notamment des obligations en matière de gouvernance, d’évaluation des facteurs relatifs à la vie privée, de gestion des incidents de confidentialité et de traitement des renseignements sensibles. Le consentement exprès peut être requis pour utiliser des renseignements personnels sensibles à une fin différente de celle prévue lors de leur collecte, sous réserve du régime applicable.

Au niveau fédéral, la LPRPDE encadre les pratiques de traitement des renseignements personnels dans les activités commerciales relevant de son champ d’application. Une organisation active dans plusieurs provinces doit identifier les règles qui s’appliquent à ses opérations et ne pas supposer qu’un cadre provincial couvre automatiquement toutes ses activités.

La protection doit aussi concerner les résultats du modèle. Une prédiction individuelle peut révéler ou suggérer une caractéristique personnelle, même lorsque cette caractéristique ne figurait pas explicitement dans les données initiales.

Une fois le périmètre des données autorisées et les risques maîtrisables identifiés, l’entreprise peut construire une première expérimentation sans chercher à transformer immédiatement tous ses processus.

Comment définir une première itération sans vouloir résoudre tout le problème ?

Une première itération réussie se concentre sur une seule décision, un jeu de données maîtrisé et un critère de performance défini avant le lancement. Elle doit permettre de vérifier, dans des conditions proches de l’usage réel, si le modèle apporte une amélioration utile. Son objectif n’est pas de produire une automatisation complète, mais de réduire l’incertitude sur la valeur du projet.

Une entreprise canadienne qui souhaite améliorer ses prévisions pourrait, par exemple, commencer par une seule catégorie de produits et un horizon de prévision précis. Chercher simultanément à anticiper les ventes, optimiser les stocks et automatiser les commandes introduirait plusieurs objectifs dont les performances seraient difficiles à isoler.

Le cadrage doit définir la décision concernée, les utilisateurs, les données disponibles, la méthode actuelle et les conditions d’arrêt. Il faut également préciser ce qui reste explicitement hors du premier périmètre.

Le délai initial doit être suffisamment court pour permettre une évaluation sans immobiliser durablement les équipes, mais assez réaliste pour inclure l’accès aux données et leur vérification. Un calendrier arbitraire n’a guère de valeur si les résultats métier nécessaires à l’évaluation ne sont pas encore observables.

Le premier cas d’usage devrait de préférence concerner une décision fréquente dont les erreurs sont détectables et récupérables. Un outil qui suggère une catégorie documentaire à un employé est ainsi souvent plus facile à expérimenter qu’un système prenant seul une décision importante concernant une personne.

La démonstration doit ensuite parcourir toute la chaîne : réception de données réelles, production d’une prédiction, examen de la recommandation et mesure du résultat obtenu. Un simple indicateur calculé sur des données historiques ne suffit pas à prouver que l’outil sera utilisé correctement.

La valeur d’une telle expérience est également organisationnelle. Elle permet de découvrir les accès manquants, les écarts entre services, les besoins de formation et les coûts de supervision. Même si le modèle n’est pas conservé, ces enseignements peuvent rendre le projet suivant plus réaliste.

Ce périmètre initial ne doit toutefois pas devenir rigide : les découvertes du projet peuvent justifier certains changements, à condition qu’ils soient évalués et décidés explicitement.

Comment garder un projet sur la bonne trajectoire lorsque les priorités évoluent en cours de route ?

Pour maintenir un projet d’apprentissage automatique sur la bonne trajectoire, l’entreprise doit fixer des critères de décision, désigner un responsable métier et réévaluer explicitement chaque changement important. Modifier le périmètre peut être légitime lorsque les données révèlent une difficulté. En revanche, changer l’objectif sans réexaminer les coûts, les risques et les indicateurs de succès peut rendre le projet impossible à évaluer.

Un projet de machine learning se distingue d’un développement informatique strictement déterministe par l’incertitude de ses résultats. Même si les fonctionnalités sont livrées conformément au cahier des charges, les performances prédictives peuvent ne pas atteindre le niveau souhaité.

Cette incertitude justifie une gouvernance fondée sur des jalons de décision plutôt que sur la seule réalisation de tâches techniques. Un premier jalon peut confirmer l’exploitabilité des données, un deuxième examiner la performance expérimentale et un troisième autoriser ou refuser une utilisation opérationnelle.

Pour chaque jalon, les critères devraient être définis avant l’évaluation :

• Le problème métier est-il toujours prioritaire ?
• Les données sont-elles suffisantes et leur utilisation est-elle autorisée ?
• La performance dépasse-t-elle celle de la méthode de référence de façon utile ?
• Les erreurs et leurs conséquences restent-elles acceptables ?
• Le coût total de poursuite est-il proportionné à la valeur attendue ?

La réponse peut déboucher sur trois décisions : poursuivre, adapter ou arrêter. Cette distinction évite qu’un projet techniquement intéressant soit prolongé alors qu’il ne répond plus à un besoin prioritaire.

Un document de cadrage vivant permet de conserver la trace des décisions. Il doit notamment contenir l’objectif, le responsable, les hypothèses, les données autorisées, les indicateurs, les risques et les changements approuvés. Lorsqu’une demande modifie la finalité initiale, une nouvelle évaluation de pertinence devient nécessaire.

Sans expertise interne importante, la responsabilité métier ne doit pas être transférée entièrement au fournisseur. L’organisation reste la mieux placée pour déterminer si les recommandations produites sont utiles, quelles erreurs sont acceptables et si les résultats répondent au processus réel.

Un arrêt ne signifie pas nécessairement que toutes les dépenses étaient inutiles. L’inventaire des données, les règles de qualité documentées, les compétences acquises et la compréhension des contraintes opérationnelles peuvent être réutilisés dans d’autres initiatives, à condition de les conserver et de les rendre accessibles.

À l’inverse, poursuivre simplement parce que des ressources ont déjà été engagées expose l’entreprise à des coûts supplémentaires sans justification nouvelle. La bonne décision repose sur les perspectives restantes, et non sur la volonté de préserver artificiellement l’investissement passé.

Pour passer à l’action, une organisation peut réunir son responsable métier, le responsable des données et, si nécessaire, un fournisseur autour d’un seul cas d’usage. La première décision à prendre est simple : déterminer quelle prédiction mérite réellement d’être testée et selon quels résultats observables elle sera jugée.