Réussir un projet IA : ce qui se joue avant le code

Réussir un projet IA se décide avant la première ligne de code¶

Ce qui fait qu'un projet IA fonctionne se décide bien avant de toucher au moindre bout de code. Pas dans le choix du modèle, pas dans le framework, pas dans le pipeline. Dans le cadrage : la problématique métier, l'objectif et sa mesure, la donnée réelle, la question de savoir si l'IA est même nécessaire, et l'utilisateur qui devra s'en servir.

Avec le temps, j'ai fini par passer le plus clair de mon énergie sur ce qui vient avant l'IA. Pas sur l'IA elle-même. C'est contre-intuitif quand on est ingénieur, mais c'est là que se joue la différence entre un projet qui tient et un projet qui finit dans un tiroir.

Clarifier la problématique métier avant tout¶

La première chose, c'est de comprendre ce qu'on essaie vraiment de résoudre. Ça paraît évident, et pourtant c'est ce qui manque dans la plupart des projets qui tombent à l'eau. On saute sur le côté technique avant d'avoir posé le problème.

J'ai vu trop de réunions parler de réseaux de neurones ou de ChatGPT sans qu'on ait jamais formulé la problématique de départ. On part de la solution, on cherche un problème à lui coller. C'est l'inverse du bon ordre.

Une problématique métier bien posée, c'est une phrase que la personne du terrain valide sans hésiter. Pas « on veut de l'IA », mais « les gestionnaires passent deux heures par dossier à chercher la bonne clause, et on veut réduire ce temps ». Tant que cette phrase n'existe pas, tout le reste est prématuré.

Fixer un objectif et savoir comment le mesurer¶

Une fois la problématique posée, vient l'objectif. Qu'est-ce qu'on veut atteindre ? 80 % de réponses justes ? Du temps gagné sur une tâche précise ? Et surtout, comment on le mesure.

Viser le 100 %, c'est impossible, et c'est même le meilleur moyen de planter le projet. Un système qui doit être parfait pour être utile ne sera jamais déployé. Il faut être réaliste et fixer une valeur minimale cohérente avec le métier, le seuil à partir duquel la solution rend déjà service.

La mesure n'est pas un détail qu'on règle à la fin. Sans cadre d'évaluation défini dès le départ, on navigue à vue : on change un paramètre, ça semble mieux sur deux ou trois exemples, on valide, et on se trompe. La bonne approche, c'est un jeu de test fixe et des chiffres, et c'est exactement ce que je détaille dans comment améliorer un RAG par l'analyse d'erreur.

Regarder vraiment à quoi ressemblent les données¶

Puis il y a la donnée. En IA générative, on a tendance à l'oublier, parce qu'on part du principe que le modèle peut tout traiter. C'est vrai, jusqu'à ce que ça ne le soit plus.

Un PDF rempli de tableaux peut être mal interprété, même par les derniers modèles. Une donnée mal structurée, des scans de mauvaise qualité, des documents incohérents entre eux : tout ça se paie plus tard, au moment où on croyait avoir fini. Les bons data scientists aiment savoir à quoi ressemble la donnée qu'ils ont entre les mains, avant de promettre quoi que ce soit.

Concrètement, ça veut dire ouvrir les fichiers, en lire une vingtaine à la main, repérer les cas tordus. C'est ingrat, ça ne se montre pas en démo, mais c'est ce qui évite les mauvaises surprises. Sur ce point précis, l'extraction et le parsing de PDF pour un RAG sont souvent là où tout se complique.

Se demander si l'IA est vraiment nécessaire¶

Quelque chose d'important en début de projet, et qui surprend souvent : prendre du recul et se demander si on ne pourrait pas résoudre le problème simplement, sans IA. Est-ce que c'est faisable autrement ? Si on voulait juste faire gagner du temps, comment on s'y prendrait ?

Parce que le métier d'un ingénieur IA ou d'un data scientist, c'est avant tout d'être pragmatique : résoudre une problématique avec la solution la plus simple possible. Parfois c'est une requête SQL, une règle, un script de quelques lignes. Si ça fait le travail, c'est la bonne réponse, et personne n'a besoin de réseau de neurones.

L'IA n'est pas une fin, c'est un outil parmi d'autres. La poser en option, et pas en point de départ, change complètement la façon de cadrer. Et quand l'IA est justifiée, la même logique s'applique au choix de l'approche : j'en parle dans agent IA contre n8n, Make ou Zapier, où la solution la plus simple n'est pas toujours celle qu'on imagine.

Penser à l'utilisateur final dès le départ¶

Et enfin, l'utilisateur qui devra se servir de la solution. Une mauvaise habitude qu'on a en data science, c'est de croire que seul le modèle compte. Sauf que dans une entreprise, c'est le dernier de leurs soucis. Un modèle qui finit dans un tiroir parce que personne ne l'utilise ne sert à rien.

Donc dès le début, il faut réfléchir avec les utilisateurs à la façon dont on va leur présenter la solution, à l'ergonomie autour, et à comment elle va s'intégrer dans leur quotidien. C'est ce qu'on croit acquis et qui ne l'est jamais. On suppose que si l'outil est bon, il sera adopté. C'est faux.

Ce qui fait qu'une solution est adoptée, ce n'est pas la performance du modèle, c'est la simplicité avec laquelle on peut s'en servir. Et l'interface n'est pas qu'une couche de présentation : bien pensée, elle devient une source de données d'amélioration en continu, un sujet que je creuse dans l'UX d'un produit IA et ses patterns de feedback.

Questions fréquentes sur le cadrage d'un projet IA¶

Pourquoi les projets IA échouent-ils le plus souvent ? Rarement à cause de la technique. Le plus souvent parce que la problématique métier n'a jamais été clairement posée, ou parce que personne n'a pensé à l'utilisateur final. Un modèle performant que personne n'utilise est un échec.

Faut-il toujours de l'IA pour résoudre un problème métier ? Non. Beaucoup de problèmes se règlent avec une solution simple : une règle, une requête, un script. Le réflexe pragmatique est de chercher d'abord la voie la plus simple, et de ne sortir l'IA que si elle apporte vraiment quelque chose en plus.

Comment mesurer la réussite d'un projet IA ? En définissant l'objectif et sa mesure avant de commencer : un taux de réponses justes, du temps gagné sur une tâche, un seuil minimal cohérent avec le métier. Sans jeu de test fixe et sans chiffres, on ne peut pas savoir si on s'améliore.

Pourquoi viser 100 % de précision est une erreur ? Parce que c'est impossible, et qu'un système qui doit être parfait pour être utile ne sera jamais déployé. Mieux vaut viser une valeur minimale réaliste, le seuil à partir duquel la solution rend déjà service au quotidien.

Pourquoi regarder les données avant de développer ? Parce que l'IA générative ne traite pas tout aussi bien qu'on le croit. Un PDF rempli de tableaux, des scans de mauvaise qualité ou des documents incohérents peuvent fausser le résultat. Ouvrir les fichiers et en lire quelques-uns à la main évite des surprises coûteuses plus tard.

À quel moment penser à l'utilisateur final ? Dès le départ, pas à la fin. L'ergonomie, la façon de présenter la solution et son intégration dans le quotidien décident de l'adoption autant que la performance du modèle, parfois davantage.

Le cadrage, c'est 80 % du travail¶

Le modèle, le framework, le pipeline : c'est la partie visible, celle dont on parle. Mais ce qui décide du sort d'un projet IA se joue avant, dans des questions qui n'ont l'air de rien. Quel problème on résout. Comment on saura qu'on a réussi. À quoi ressemble la donnée. Si l'IA est même nécessaire. Qui va s'en servir.

Les négliger, c'est construire vite quelque chose que personne n'utilisera. Les traiter sérieusement, c'est se donner une vraie chance que la solution serve. C'est tout le sens du travail d'un consultant IA : commencer par le métier, pas par la technique.

Si mes articles vous intéressent et que vous avez des questions ou simplement envie de discuter de vos propres défis, n'hésitez pas à m'écrire à anas@tensoria.fr, j'aime échanger sur ces sujets !

Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi¶

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.