La thèse en une phrase : changer de modèle d’IA, c’est la première chose qu’on fait quand quelque chose cloche et la dernière qu’on devrait faire. Un nouveau modèle sort, quelqu’un lit qu’il est plus malin, et la conversation de l’équipe passe de « pourquoi ça ne rend pas ? » à « on bascule sur le dernier ? ». C’est la réaction la plus confortable du monde —elle n’exige pas de regarder à l’intérieur— et presque toujours la mauvaise. Le goulot d’étranglement, c’est rarement le modèle. C’est le processus que personne n’a bien défini et les données que personne n’a nettoyées.
Changer de modèle d’IA, c’est traiter le symptôme, pas la maladie
Quand un projet d’IA déçoit, il y a deux coupables possibles : le moteur ou tout ce qui l’entoure. Le moteur, c’est le modèle ; ce qui l’entoure, c’est comment l’information lui arrive, ce qu’on lui demande, avec quelles données il travaille et ce qu’on fait de sa réponse. L’industrie entière te pousse à regarder le moteur, parce que c’est ce qui se vend, se compare et fait les gros titres. Mais dans la plupart des projets qui coincent, le moteur n’est pas le problème : le problème, c’est que tu lui demandes de deviner sur un processus que toi-même tu n’as pas au clair, nourri avec des données qui se contredisent entre elles.
Prends une analogie ennuyeuse mais exacte : si ta voiture ne démarre pas parce que le réservoir est vide, remplacer le moteur par un plus puissant ne la fait pas avancer d’un mètre. Changer de modèle quand le frein, c’est le processus, c’est exactement ça —un chantier coûteux qui ne touche pas à la cause—. Et pendant ce temps, l’équipe se persuade qu’elle « a tout essayé », alors qu’en réalité elle n’a pas touché à la seule chose qui comptait.
Le vrai goulot d’étranglement : processus mal défini et données sales
Un modèle d’IA vaut ce que vaut la clarté du travail que tu lui confies et la qualité de ce que tu lui donnes pour travailler. Quand il échoue, il échoue presque toujours à cause de l’une de ces deux choses, pas d’un manque d’intelligence brute :
Processus mal défini
Si toi, tu ne peux pas expliquer le processus en étapes claires, l’IA ne va pas l’inventer à ta place. Beaucoup de « cas d’usage de l’IA » sont en réalité des processus qui n’ont jamais été documentés : chacun les faisait à sa façon, avec des exceptions dans la tête et des critères que personne n’a écrits. Tu demandes à l’IA d’automatiser ce chaos et, logiquement, elle produit du chaos avec une meilleure grammaire. Un modèle plus puissant ne va pas te donner la définition du processus qui te manque. Comment découper une tâche en instructions qu’une IA peut vraiment suivre, c’est la moitié du travail, et on l’aborde dans automatiser des tâches avec ChatGPT.
Données sales
L’autre moitié, c’est de quoi elle se nourrit. Si l’IA répond à partir d’informations périmées, dupliquées, contradictoires ou éparpillées dans dix endroits qui ne se parlent pas, la réponse sera mauvaise même si le modèle est excellent. Camelote en entrée, camelote en sortie —aucune release ne répare ça—. Ce frein est si courant qu’on lui consacre un article entier : les données en vrac sont le vrai frein de l’IA. Et si ton cas exige que le modèle connaisse ton business, le remède, c’est presque jamais de changer de modèle : c’est de lui donner un accès ordonné à ton information, ce qu’on décortique dans entraîner l’agent avec ta propre information.
Pourquoi changer de modèle est si tentant (et si inutile)
Si le problème, c’est presque toujours le processus, pourquoi la réaction par défaut, c’est de changer de modèle ? Parce que c’est facile. Changer de modèle, c’est une décision d’un après-midi : tu touches un réglage, tu pointes vers un autre endpoint et c’est réglé. Réparer le processus et les données, c’est une décision de plusieurs semaines, ça exige de parler aux gens qui font le travail, de documenter ce que personne n’a documenté et de nettoyer ce que personne ne veut nettoyer. Devant ce choix, l’humain préfère celui qui a l’air d’un progrès sans être inconfortable.
- Ça donne une sensation d’action sans en être une. Migrer de modèle, ça semble productif —il y a quelque chose à toucher, un avant et un après— même si le résultat ne bouge pas. C’est du théâtre de progrès.
- Le marketing te fournit l’alibi. Chaque release arrive avec des benchmarks qui promettent un bond. C’est ultra facile de te convaincre que CELUI-CI, c’est le bon qui manquait, plutôt que d’accepter que la panne est chez toi.
- Regarder à l’intérieur, ça dérange. Reconnaître que ton processus n’était pas défini ou que tes données sont un désastre pointe vers tes propres décisions. Changer de fournisseur externalise la faute : c’est le modèle, pas nous.
Et il y a un coût que presque personne ne comptabilise : chaque migration de modèle n’est pas gratuite. Tu réécris des prompts, tu revalides des résultats, tu ajustes l’intégration et tu retestes tout. Si tu fais ça en poursuivant un problème qui n’était pas dans le modèle, tu dépenses cet effort pour finir au même endroit —avec le processus tout aussi cassé, mais avec un modèle différent à qui refiler la faute la prochaine fois—.
Quand changer de modèle est vraiment la bonne décision
Ce n’est pas « ne change jamais de modèle ». Parfois le moteur est bel et bien la limite, et alors changer est le geste sensé. La différence, c’est que tu le fais après avoir écarté le reste, pas avant de l’avoir regardé. Voici les signes que le modèle est vraiment ton plafond :
- Un humain avec tes mêmes instructions et données le fait bien, et l’IA non. Si la tâche est bien définie, les données sont propres et une personne avec cette même information réussit, mais le modèle échoue sur un type de raisonnement précis, là oui, le moteur est la limite.
- Tu butes sur une vraie limite technique. Fenêtre de contexte insuffisante pour ton cas, langue que le modèle gère mal, latence ou coût au token qui ne collent pas à ton volume : ce sont des limites du moteur, pas du processus.
- Tu l’as testé à conditions égales. Tu as changé uniquement le modèle, avec le même processus et les mêmes données déjà rangées, et le nouveau gagne de façon mesurable et répétable —pas sur une démo chanceuse—.
Regarde bien l’ordre : d’abord tu répares processus et données, et seulement ensuite, sur cette base propre, comparer des modèles devient une décision sensée au lieu d’une fuite en avant. Sur comment monter cette base pour pouvoir changer de moteur sans douleur —en découplant l’application du fournisseur— on a écrit dans IA open source vs API fermée.
Quoi faire lundi au lieu de changer de modèle
- Écris le processus à la main, en étapes. Si tu ne peux pas l’expliquer en une page claire, l’IA ne va pas rattraper ce que tu n’as pas défini. Ce document, c’est le remède, pas le modèle.
- Regarde de quelles données l’IA se nourrit. Remonte l’information qu’elle utilise jusqu’à sa source et vérifie si elle est à jour, unique et non contradictoire. Range ça avant de toucher à quoi que ce soit d’autre.
- Fais le test du nouvel employé. Un humain brillant avec ces instructions et ces données ferait-il bien la tâche ? Si non, répare les instructions et les données. Si oui et que l’IA échoue, alors —et seulement alors— compare les modèles.
Si en faisant ça tu découvres que le frein, ce n’était pas le modèle mais le processus —ce qui est le plus probable—, c’est exactement le travail qu’on fait : définir le processus, ranger les données et laisser l’automatisation tourner par-dessus, avec automatisation des opérations. Le modèle, c’est la partie facile ; que le travail soit bien fait, la difficile.