Réussir un projet d'IA: clarifier la nature du problème avant d'investir
Une entreprise manufacturière dispose de 30 ans d'historique de production, et veut un système d'IA pour optimiser sa planification. Une fois que le projet est livré, le client réalise que l'historique n'a pas servi à entraîner le modèle.
Le réflexe naturel face à cette information est de penser qu'il y a une erreur. Trente ans de données réelles, terrain, vivantes, ignorées par un système d'IA, ça défie l'intuition que tout le monde a sur ce que fait l'intelligence artificielle.
L'erreur n'est pas dans le projet, mais plutôt dans l'intuition.
L'IA regroupe plusieurs familles d'approches qui résolvent des problèmes très différents. Les deux principales, en contexte d'entreprise, sont l'apprentissage et l'optimisation. Confondre les deux est probablement la source la plus fréquente de désalignement entre ce qu'un client espère d'un projet IA et ce qu'un projet IA peut effectivement livrer.
L'apprentissage: déduire à partir d'exemples
La première famille regroupe ce que la plupart des gens imaginent quand ils entendent «intelligence artificielle». Un modèle observe un grand nombre d'exemples passés, repère des régularités, et applique ces régularités à de nouveaux cas.
Une fissure repérée sur la photo d'un pont, une prédiction de consommation énergétique pour un bâtiment, un courriel classé automatiquement dans la bonne file, une pièce défectueuse identifiée par une caméra sur la ligne de production: dans tous ces cas, le modèle a besoin d'exemples annotés pour apprendre, c'est-à-dire d'une banque de cas passés où la bonne réponse est déjà connue. Ces exemples servent aussi à mesurer la qualité du modèle, y compris pour ceux qu'on peut utiliser tels quels sans entraînement supplémentaire.
Cette famille est gourmande en données. Plus on en a, mieux c'est. C'est de cette famille que vient l'image populaire de l'IA qui se nourrit de données.
L'optimisation: calculer la meilleure combinaison possible
La deuxième famille fonctionne sur une logique différente. Le problème, cette fois-ci, n'est pas de prédire ce qui va arriver, mais de décider quelle est la meilleure action possible étant donné un état actuel et un ensemble de règles.
Planifier la production d'une usine pour la semaine à venir entre dans cette logique, tout comme affecter du personnel à des projets selon les compétences requises et les disponibilités, ou encore déterminer la tournée la plus efficace pour un camion qui doit visiter douze adresses dans la même journée. Ces problèmes partagent une structure commune: un état actuel connu, des contraintes connues, un objectif à atteindre, et un nombre énorme de combinaisons possibles parmi lesquelles il faut trouver la meilleure.
L'historique, dans ces problèmes, n'est pas une matière première. Une planification optimale pour une semaine donnée dépend du carnet de commandes de cette semaine-là, des ressources disponibles à ce moment précis, et des contraintes en vigueur. Une planification passée a été optimale pour ses propres conditions et n'enseigne rien sur la planification idéale d'aujourd'hui.
Quand un historique existe pour ce type de problème, il garde son utilité, mais ailleurs que dans l'entraînement. Reconstruire des situations passées et comparer la solution réellement choisie à l'époque avec celle que l'optimisation aurait produite donne un banc d'essai pour valider la qualité du moteur. C'est un usage rétrospectif.
Quand les deux logiques s’appliquent
Plusieurs projets réels combinent les deux familles. Une optimisation de tournée logistique peut s'appuyer sur un modèle qui prédit les temps de trajet en fonction de l'heure et de la météo, puis utiliser ces prédictions comme intrants pour le calcul de la meilleure tournée. Une planification de production peut intégrer un modèle qui prédit les pannes machine probables, pour bâtir des horaires plus robustes.
Dans ces cas hybrides, chaque composante apporte de la valeur sur ce qu'elle sait faire. L'apprentissage extrait des régularités à partir des données disponibles, et l'optimisation s'appuie sur ces régularités pour calculer la meilleure décision possible. La frontière entre les deux familles devient alors une articulation, à condition que chacune reste à sa place dans la chaîne de traitement.
Comment situer son problème
Avant de se demander comment l'IA pourrait être implantée dans une organisation, il faut d'abord comprendre la nature du problème qu'on cherche à résoudre. Cette étape précède le développement, le choix d'une technologie, et même la sélection d'un partenaire. Elle relève de la responsabilité du client, parce que personne d'autre ne connaît aussi bien ses propres opérations. Identifier la famille à laquelle appartient un problème ne demande pas de connaissances techniques avancées; cela demande surtout de prendre le temps de réfléchir à ce que la solution est censée produire, et au rôle que les données joueront dans cette production.
Beaucoup de projets s'engagent sans que cette clarification soit faite, soit parce qu'elle semble évidente, soit parce qu'on présume que le fournisseur s'en occupera. Le résultat, quand l'exercice est sauté, est presque toujours le même: un décalage qui n'apparaît qu'au milieu du projet, quand les choix techniques ont déjà été faits et qu'il devient coûteux de les remettre en question. Deux questions, posées tôt, suffisent à éviter ce piège.
La première question concerne ce que la solution doit produire au final. Est-ce que la solution doit décrire ce qui est probable, ou décider ce qui est optimal? Prédire ce qui va probablement se passer relève d'une logique d'apprentissage, et décider de la meilleure action possible relève d'une logique d'optimisation. Un modèle qui anticipe quels équipements risquent de tomber en panne, ou quels clients risquent de partir, déduit ses prédictions à partir d'exemples passés observés sur le terrain. La nature du livrable attendu suffit la plupart du temps à orienter la conversation dans la bonne direction.
La deuxième concerne le rôle des données historiques. Sans données, est-ce qu'on peut quand même résoudre le problème, ou est-ce qu'il s'effondre complètement? Pour un problème d'apprentissage, les données sont la matière première: sans elles, ou sans un équivalent valable comme un jeu de données public ou des données synthétiques, il n'y a rien à modéliser. Pour un problème d'optimisation, les données ne sont qu'un point de comparaison: utiles à avoir, pas nécessaires pour avancer.
Ces deux questions évitent les premiers malentendus, qui sont aussi les plus coûteux à corriger en cours de projet.
La bonne question avant la bonne réponse
L'idée que l'IA, pour fonctionner, exige d'abord beaucoup de données est vraie pour une famille de problèmes. Elle est trompeuse pour l'autre. Un dirigeant qui démarre un projet en demandant «combien d'années d'historique ai-je besoin?» pose la mauvaise question pour une partie de ses cas d'usage potentiels. La meilleure question dépend de la nature du problème, et identifier cette nature est la première étape d'un projet bien cadré.
Choisir la bonne approche avant d'investir, c'est déjà une bonne partie du travail.
Explor.ai joue ce rôle auprès des organisations qui démarrent un projet d'IA: poser les bonnes questions avant la première ligne de code, identifier la nature réelle du problème, et orienter l'investissement vers une approche qui correspond au besoin.
Si vous préparez un projet et hésitez sur la direction à prendre, une rencontre exploratoire avec notre équipe peut vous aider à clarifier l'essentiel avant d'engager le budget.
