Mettre de l'IA partout n'est pas de l'ingénierie

J'ai vu un développeur passer trois jours à fine-tuner un modèle pour résoudre un problème de tri.

Un algorithme de 40 lignes aurait fait exactement la même chose. Zéro coût d'API, zéro latence réseau, zéro dépendance à un service tiers. Trois jours de travail qualifié pour réinventer, moins bien, ce qu'une fonction de tri standard fait depuis des décennies.

Ce n'est pas un cas isolé. C'est le nouveau syndrome de la complexité en ingénierie logicielle. Il y a dix ans, on over-engineerait avec des microservices pour un produit qui tenait dans un monolithe. Aujourd'hui, on over-engineere avec de l'IA pour des problèmes qu'une règle métier de trois lignes résout aussi bien, plus vite, et de façon prévisible.

Le réflexe qui coûte cher : "est-ce qu'on peut mettre de l'IA là-dedans ?"

C'est devenu la question par défaut dès qu'une équipe conçoit une fonctionnalité. Elle part d'une bonne intention - rester à la pointe, exploiter un outil puissant - mais c'est rarement la bonne question à poser en premier.

La question qui devrait venir avant : quel problème est-ce qu'on essaie de résoudre, et quelle est la solution la plus simple qui le résout correctement ? Poser la question de l'IA avant celle du problème inverse l'ordre logique de toute décision d'architecture, et le résultat se paie sur trois plans à la fois : le coût, la latence, et la prévisibilité du comportement du système.

Trois exemples concrets illustrent où cette inversion coûte le plus cher.

Un LLM pour recommander des produits à 200 utilisateurs

Un algorithme de scoring basique - historique d'achat, catégories consultées, quelques règles de pondération - fait le travail pour 0€ d'appel API et un temps de réponse proche de zéro milliseconde. Un LLM appelé à chaque recommandation ajoute une latence réseau, un coût par requête qui grandit avec le trafic, et un comportement dont la logique interne reste largement opaque. Sur un volume de 200 utilisateurs, la variance apportée par un modèle de langage ne compense jamais le surcoût qu'il introduit.

Un agent IA pour router des tickets support

Trois conditions if/else couvrent 80% des cas de routage réels : mot-clé dans le sujet, catégorie sélectionnée par l'utilisateur, historique du compte. Le reste - les 20% ambigus, qui touchent réellement à la compréhension du langage naturel - va à un humain, ou à un LLM ciblé sur ce sous-ensemble précis. Faire passer 100% des tickets par un agent IA pour un problème que des règles déterministes résolvent à 80% revient à payer le coût d'un système probabiliste sur des cas qui n'en ont pas besoin.

Un RAG pour chercher dans 50 documents internes

Une recherche full-text indexée répond en quelques millisecondes, sans coût d'inférence, et sans risque d'hallucination. Un pipeline RAG - embeddings, base vectorielle, appel LLM pour reformuler la réponse - a du sens quand le corpus est large, la requête ambiguë, et la synthèse entre plusieurs sources nécessaire. Sur 50 documents, l'essentiel de cette complexité ne sert à rien : l'utilisateur veut retrouver un document, pas une synthèse générée.

Puissant ne veut pas dire universel

L'IA générative excelle sur les problèmes non structurés : langage ambigu, contexte variable, tâches qu'on ne sait pas décrire complètement sous forme de règles explicites. C'est exactement pour ces problèmes-là qu'elle a été conçue, et c'est là qu'elle apporte une valeur qu'aucune autre approche ne reproduit facilement.

Sur le reste - un tri, un routage à règles simples, une recherche indexable - elle n'ajoute rien qu'une fonction pure ne fournissait déjà, et elle ajoute en échange trois choses dont personne ne parle au moment du choix technique : un coût d'API récurrent qui grandit avec l'usage, une latence réseau qui n'existe pas dans un calcul local, et un comportement non déterministe qui complique le débogage et les tests. Confondre "l'IA peut faire ça" avec "l'IA doit faire ça" est l'erreur d'architecture la plus fréquente que je vois depuis deux ans en mission.

La question à poser avant de brancher un LLM sur quoi que ce soit

Avant de connecter une fonctionnalité à un modèle de langage, une seule question mérite d'être posée en premier : est-ce qu'un algorithme déterministe, une expression régulière, ou une règle métier simple ne résout pas déjà 90% du problème ?

Dans la grande majorité des cas que je croise en audit technique, la réponse est oui. Ce n'est pas une question rhétorique destinée à écarter l'IA par principe - c'est un filtre qui permet de réserver l'IA aux cas où elle apporte réellement quelque chose qu'aucune autre approche ne fournit à un coût comparable.

Concrètement, cette grille se décline en quatre vérifications avant tout branchement sur un LLM :

1. Le problème est-il structuré ? Si l'entrée et la sortie suivent des règles qu'on peut énumérer, un algorithme classique les couvre mieux qu'un modèle probabiliste.
2. Le volume justifie-t-il le coût ? Un coût par appel API négligeable à 10 utilisateurs devient une ligne budgétaire significative à 100 000 utilisateurs. Le calcul doit se faire à l'échelle cible, pas au volume du prototype.
3. La latence ajoutée est-elle acceptable pour l'usage ? Un appel réseau vers un modèle ajoute systématiquement plusieurs centaines de millisecondes qu'un calcul local n'a pas. Sur un parcours critique, ce délai a un coût produit réel.
4. Le comportement doit-il être garanti, ou seulement plausible ? Une règle métier produit toujours le même résultat pour la même entrée. Un LLM produit un résultat plausible, avec une marge d'erreur qu'il faut assumer et surveiller.

Un problème qui échoue à ces quatre filtres - non structuré, volume qui justifie le coût, latence tolérable, résultat plausible suffisant - est un bon candidat pour l'IA. Un problème qui les passe tous haut la main n'en a simplement pas besoin.

FAQ : quand utiliser l'IA plutôt qu'un algorithme classique

Comment savoir si un problème a vraiment besoin d'un LLM ?

Un problème a besoin d'un LLM quand il est non structuré - langage naturel ambigu, contexte variable, règles impossibles à énumérer complètement - et que le volume d'usage justifie le coût d'inférence associé. Si le problème peut se décrire sous forme de règles finies (tri, filtrage, routage sur des critères connus), un algorithme déterministe le résout mieux, plus vite, et à coût nul ou marginal.

Pourquoi un algorithme classique est-il souvent préférable à un LLM pour des tâches simples ?

Parce qu'un algorithme déterministe a un coût d'exécution proche de zéro, une latence locale négligeable, et un comportement garanti et testable. Un LLM ajoute systématiquement un coût par appel, une latence réseau de plusieurs centaines de millisecondes, et une marge d'incertitude sur le résultat produit. Sur une tâche que des règles couvrent déjà, ces trois coûts n'ont aucune contrepartie en valeur ajoutée.

Sur quel type de problème l'IA générative apporte-t-elle une vraie valeur ?

Sur les problèmes non structurés : compréhension de langage naturel ambigu, synthèse entre plusieurs sources hétérogènes, génération de contenu qui varie selon le contexte, classification de cas qu'on ne sait pas décrire exhaustivement sous forme de règles. C'est dans ces zones que l'IA remplace un travail qu'aucun algorithme classique ne peut raisonnablement automatiser.

Un agent IA est-il toujours la meilleure solution pour automatiser un workflow métier ?

Non. Un agent IA a du sens quand le workflow comporte des décisions ambiguës qui varient selon le contexte et ne se réduisent pas à des règles fixes. Quand la majorité des cas suit une logique simple et prévisible - comme le routage de tickets support sur des critères connus - des conditions déterministes couvrent l'essentiel du volume à un coût largement inférieur, et l'agent IA ne traite que les cas réellement ambigus.

Comment éviter l'over-engineering avec l'IA dans une équipe produit ?

En imposant une question de cadrage avant tout projet impliquant un LLM : est-ce qu'une règle métier, une regex, ou un algorithme déterministe ne résout pas déjà 90% du problème ? Cette question, posée systématiquement avant le choix technique plutôt qu'après le développement, évite la majorité des cas où l'IA est ajoutée par réflexe plutôt que par nécessité réelle.

Ce que je recommande, en tant que CTO hands-on

Le meilleur code IA est parfois celui qu'on n'écrit pas. Ce n'est pas une posture anti-IA - j'intègre des agents autonomes, du RAG et des pipelines LLMOps dès que le problème le justifie réellement, et ça reste une part significative des missions que je mène. C'est une discipline d'ingénierie : ne pas confondre "on peut le faire avec de l'IA" et "c'est la solution qui sert le mieux le produit et le budget".

En mission CTO hands-on, cette grille de décision fait partie des premiers réflexes que j'installe avec une équipe, avant même de discuter d'implémentation : qualifier chaque problème sur sa structure, son volume et sa tolérance à l'incertitude, avant de choisir l'outil. Que ce soit sur un audit ponctuel de choix techniques ou un accompagnement long où je code et j'architecture au quotidien, l'objectif reste le même - livrer la solution la plus simple qui tient dans la durée, pas la plus impressionnante à présenter.

L'IA est un outil puissant. Puissant ne veut pas dire universel.