← Blog premier projet IA entreprise

Ce que personne ne dit avant un premier projet d'IA

Enseignements des premiers projets d'IA en entreprise : difficultés réelles, surprises fréquentes et comment s'y préparer pour réussir.

Le premier projet d’IA d’une entreprise est une expérience d’apprentissage autant qu’un projet technologique. Les entreprises qui sont déjà passées par cette étape font état de surprises et d’enseignements remarquablement proches, quels que soient leur secteur et leur taille.

Cet article rassemble ces enseignements : ceux que l’on tire de projets réels, et non ceux des cas de réussite soigneusement mis en forme.

La surprise des données

La première grande surprise de presque tout premier projet d’IA, c’est l’état des données. L’entreprise était certaine d’avoir de bonnes données. Dans la plupart des cas, elle en a, mais dans un état très éloigné de ce dont le projet a besoin.

Les données sont réparties dans quatre systèmes dont les identifiants ne correspondent pas. L’historique qui semblait complet présente des lacunes importantes sur les variables essentielles. Le système censé enregistrer les retours clients le faisait différemment selon l’opérateur qui saisissait l’information. La donnée décisive pour le modèle n’est capturée dans aucun système numérique : elle se trouve sur des feuilles papier ou dans la tête du responsable du service.

Aucune de ces situations n’est exceptionnelle : c’est la norme. La meilleure préparation pour un premier projet d’IA consiste à partir du principe que les données demanderont du travail, et non qu’elles seront prêtes à l’emploi.

La question de la définition de la réussite

Deuxième constat très fréquent : la réussite du projet n’avait pas été clairement définie au départ. « Améliorer la précision des prévisions » est ambigu. « Ramener les ruptures de stock sur les références A de l’entrepôt central de 15 % à moins de 5 % » est une définition concrète de la réussite.

Sans définition claire de la réussite, trois choses se produisent : l’équipe technique optimise des indicateurs qui ne sont pas les plus pertinents pour l’activité, la direction n’a pas de critère clair pour juger si le projet a fonctionné, et le projet peut aboutir à un modèle techniquement correct que personne n’adopte, parce qu’il ne résout pas le problème le plus pressant.

Le temps consacré à définir la réussite de façon mesurable avant de commencer le développement est toujours du temps bien investi.

La sous-estimation du travail d’intégration

Construire le modèle est la partie visible du projet. Le relier aux systèmes réels de l’entreprise (ERP, CRM, outils opérationnels) est ce qui transforme le modèle en valeur métier ; c’est aussi la partie la plus souvent sous-estimée, en temps comme en complexité.

Les systèmes de nombreuses entreprises ont des décennies d’histoire, des développements spécifiques et, souvent, une documentation d’intégration incomplète ou obsolète. Une intégration qui paraissait simple sur le papier peut exiger un travail d’analyse important avant de pouvoir être réalisée.

Le conseil pratique : même pour le projet le plus simple, réserver explicitement du temps et du budget à la phase d’intégration, et ne pas estimer ce temps avant d’avoir audité l’infrastructure existante.

L’adoption prend plus de temps que prévu

Un modèle en production que l’équipe n’utilise pas ne crée aucune valeur. Et l’adoption suit son propre rythme, rarement instantané.

Les premiers jours ou les premières semaines après le lancement sont décisifs. L’équipe se pose des questions qui n’étaient pas apparues pendant la formation. Le système produit un résultat inattendu qui crée de la méfiance. Travailler avec le système n’est pas tout à fait comme travailler sans, et cela demande une adaptation.

Les entreprises qui gèrent bien cette période disposent d’un support actif pendant les premiers jours d’utilisation réelle : une personne à qui l’équipe peut s’adresser lorsque quelque chose ne fonctionne pas comme prévu. Celles qui la gèrent mal voient leurs équipes revenir au processus manuel dès que le système produit un résultat qu’elles ne comprennent pas.

Ce que personne ne mesure, et qui compte le plus

Les projets d’IA produisent deux types d’apprentissage : celui du système (le modèle s’améliore avec davantage de données et de retours) et celui de l’organisation (l’équipe comprend mieux comment travailler avec l’IA, repère de nouvelles opportunités et se forge un jugement sur ce que l’IA peut faire ou non).

Le second est le plus précieux à long terme, et le moins mesuré. Les entreprises qui progressent le plus en IA sont celles qui, après leur premier projet, disposent d’une équipe ayant acquis une intuition des problèmes que l’IA peut résoudre, et qui identifient déjà le deuxième et le troisième projet avant même que le premier soit pleinement stabilisé.

Les décisions qui changent le résultat

Certaines décisions, prises avant le démarrage du projet, ont un impact disproportionné sur le résultat :

Commencer par le bon problème. Ni le plus ambitieux ni le plus intéressant sur le plan technologique : celui qui dispose de données suffisantes, d’un impact métier mesurable et de perspectives d’adoption réalistes.

Désigner un responsable interne du projet. Une personne de l’entreprise qui a l’autorité pour prendre des décisions sur le projet, le temps de s’y consacrer et la volonté qu’il réussisse. Sans ce responsable interne, les projets s’essoufflent à la première difficulté.

Fixer des indicateurs de réussite métier avant de commencer. Et les valider avec la direction avant que le projet n’avance, pour qu’ils ne changent pas en cours de route.

Prévoir l’après-lancement dès le départ. La période de stabilisation qui suit le lancement fait partie du projet, ce n’est pas un supplément. L’intégrer au planning évite que le projet soit « oublié » dès que l’équipe externe estime avoir terminé son travail.

Questions fréquentes

À partir de quelle taille d’entreprise un projet d’IA a-t-il du sens ? Il n’y a pas de seuil de taille. Il y a un seuil de volume : si le processus à automatiser ou à améliorer est suffisamment fréquent et a suffisamment d’impact, l’IA peut avoir du sens quelle que soit la taille de l’entreprise. Des entreprises de toutes tailles ont trouvé des cas d’usage où l’IA générative ou l’automatisation offrent un retour positif.

Vaut-il mieux commencer par un grand projet ambitieux ou par un petit projet ? L’expérience montre de façon constante qu’un projet de périmètre limité mais bien exécuté, qui crée une valeur réelle et visible dans un délai raisonnable, a plus d’impact à long terme qu’un grand projet qui tarde à montrer des résultats. Le petit projet installe la confiance dans la technologie, nourrit l’apprentissage de l’organisation et obtient le soutien de la direction pour des projets plus ambitieux.

Qu’ont de différent les entreprises qui réussissent leur premier projet d’IA ? Trois choses : le problème était bien défini avant de commencer, un sponsor interne disposait de l’autorité et du temps nécessaires pour porter le projet, et l’équipe a été associée à la conception dès le début, au lieu de se voir présenter un système terminé avec la consigne de l’utiliser.