Lorsque l'on commence à construire avec l'intelligence artificielle, les voix les plus fortes pointent toutes vers la même chose : le modèle. Choisissez le bon, disent-ils, et tout le reste suivra. Après quelques semaines de mes propres expérimentations, je peux vous dire que ce n'est tout simplement pas vrai. Choisir entre les grands modèles de langage disponibles est important, mais cela ne représente peut-être que vingt pour cent du travail. Le reste relève de l'ingénierie système. C'est de la tuyauterie, de l'artisanat et des tests incessants. Cette prise de conscience m'est venue tôt, et elle a remodelé ma façon d'aborder chaque projet depuis lors.

Le modèle n'est que le début

Il est facile de comprendre pourquoi les débutants s'obsèdent pour les modèles. Les notes de mise à jour promettent un meilleur raisonnement, des fenêtres de contexte plus larges et des sorties plus propres. Ces améliorations sont réelles, mais elles sont aussi polyvalentes. Un modèle de pointe ne connaîtra pas automatiquement la politique de remboursement de votre entreprise. Il ne formatera pas de manière fiable les réponses pour votre application mobile à moins que vous ne lui indiquiez comment faire. Il ne peut pas extraire des données d'inventaire en temps réel du néant.

J'ai appris cela à mes dépens. Mon premier prototype utilisait un modèle performant et produisait de magnifiques paragraphes assurés, mais qui étaient parfois complètement erronés. Le texte semblait professionnel parce que le modèle avait maîtrisé le ton, mais il n'avait aucun accès aux informations actuelles. J'avais passé des jours à comparer des benchmarks de modèles alors que j'aurais dû réfléchir aux pipelines de données et à l'injection de contexte. Le modèle n'était pas défaillant. C'est le système qui l'entourait qui était incomplet. Cette distinction est primordiale lorsque l'on passe de simples démos à des logiciels sur lesquels les gens comptent réellement.

Les prompts sont du code, pas des suggestions

Des prompts de haute qualité sont au cœur de toute application IA fiable. Au début, je traitais les prompts comme des requêtes de recherche — courts, informels, optimistes. Je demandais à un modèle de « résumer ceci » ou d'« être utile » en espérant le meilleur. Les résultats oscillaient sauvagement entre l'utile et l'irrelevant, et je n'avais aucune idée de la raison.

Désormais, je traite les prompts comme des programmes légers. Un bon prompt définit le rôle, spécifie le format de sortie, inclut des exemples si nécessaire et fixe des limites. Si je veux du JSON, je demande du JSON et je montre le schéma. Si j'ai besoin d'une réponse concise, je limite explicitement la longueur et j'interdis le préambule. L'itération est cruciale. Je tiens un journal de bord des prompts et de leurs résultats, en ne changeant qu'une variable à la fois. Un seul adjectif ambigu dans un prompt peut modifier le comportement de l'ensemble d'un flux de travail. Cette sensibilité exige de la rigueur, pas des suppositions.

Des données erronées, des résultats erronés

La récupération fiable des données est l'endroit où de nombreux projets d'IA meurent silencieusement. La génération augmentée par récupération, ou RAG (Retrieval-Augmented Generation), est devenue le modèle standard pour donner aux modèles accès à des données privées ou actuelles. L'idée est simple : récupérer les documents pertinents, les injecter dans la fenêtre de contexte du modèle et laisser le modèle raisonner sur les faits. La pratique est beaucoup plus complexe.

J'ai passé du temps à déboguer une base de connaissances simple qui ne cessait de renvoyer des résultats sans rapport. Le modèle fonctionnait bien. C'était la couche de récupération qui échouait. Mes segments (chunks) étaient trop petits et dépourvus de contexte. Mes embeddings étaient générés sans nettoyer les en-têtes en double. La recherche de similarité trouvait des textes techniquement proches qui répondaient à la mauvaise question. Pour corriger cela, j'ai dû repenser la stratégie de découpage, ajouter des filtres de métadonnées et introduire une étape de re-classement (re-ranking). Une fois la récupération stabilisée, les réponses du modèle se sont instantanément améliorées. La leçon était claire : on ne peut pas compenser une mauvaise récupération de données avec un meilleur modèle. Il faut construire le pipeline correctement.

On ne peut pas améliorer ce que l'on ne mesure pas

L'évaluation constante est l'habitude qui sépare les expérimentations des produits. Quand j'ai commencé, j'évaluais au feeling. Je lisais cinq résultats, hochais la tête d'un air approbateur, et passais à la suite. Cela fonctionne jusqu'à ce qu'un utilisateur pose la sixième question et obtienne quelque chose de bizarre.

Désormais, je construis de petits jeux d'évaluation pour chaque fonctionnalité. Je collecte les requêtes réelles des utilisateurs, je définis le comportement attendu et j'exécute des tests automatisés par rapport à ceux-ci. Je surveille la dérive (drift) : un prompt qui fonctionnait le mois dernier peut se dégrader après une mise à jour du modèle ou après un changement des données sous-jacentes. Je sépare l'évaluation du style de l'exactitude factuelle. Avoir un aspect professionnel est une bonne chose ; être correct est obligatoire. Sans cette boucle, vous livrez vos produits en vous basant sur l'espoir, et l'espoir n'est pas une stratégie de test.

Connaissez les limites de la machine

Comprendre les limites des modèles m'a évité de faire des promesses excessives pour des résultats décevants. Ces systèmes ont de réelles contraintes. Les fenêtres de contexte sont plus larges qu'auparavant, mais elles ont toujours des plafonds, et les saturer dégrade les performances aux limites. Les modèles hallucinent, surtout sur des sujets de niche où les données d'entraînement sont rares. Ils ont du mal avec l'arithmétique précise et certains types de logique multi-étapes. Ils sont sensibles à la formulation.

Le coût et la vitesse sont également des limites. Un modèle qui génère une prose parfaite en dix secondes peut s'avérer inutilisable dans une interface de chat en temps réel. Je planifie désormais les fonctionnalités en fonction de budgets de latence dès le début. Si une tâche nécessite une réponse en moins d'une seconde, je peux précalculer les réponses, mettre en cache de manière agressive, ou utiliser un modèle plus petit pour le premier jet et un modèle plus grand uniquement pour l'affinage. Travailler avec des contraintes est une pratique d'ingénierie standard. L'IA ne fait pas exception.

Construire pour de vraies personnes

J'étudie actuellement les applications de LLM et le génie logiciel avec un objectif simple : construire des outils que les gens utilisent quotidiennement. Cela semble évident, mais l'écart entre un prototype impressionnant et un outil d'usage quotidien est massif. Une démo peut tolérer une pause de quarante secondes et une réponse verbeuse. Une personne qui essaie de terminer une tâche avant une réunion ne le peut pas.

Les outils d'usage quotidien nécessitent une gestion des erreurs, des solutions de repli et une interface utilisateur claire lorsque le modèle est incertain. Ils doivent s'intégrer aux flux de travail existants plutôt que d'en imposer de nouveaux. Je pense désormais aux cas limites : que se passe-t-il lorsque le modèle refuse de répondre, lorsque le contexte déborde ou lorsque l'API expire ? Livrer un logiciel d'IA signifie répondre à ces questions par le code, et non par le simple optimisme.

Partageons ce que nous apprenons

Je souhaite entrer en contact avec d'autres développeurs qui suivent le même chemin. Le domaine évolue rapidement et les meilleures pratiques sont encore en train d'être écrites. Personne n'a toutes les réponses. Que vous vous battiez avec la conception de prompts, les pipelines de récupération ou la manière d'évaluer les résultats à grande échelle, les problèmes se résolvent mieux ensemble.

Partageons ce que nous apprenons. Pas des conférences de haut vol, mais la réalité du terrain. Les pipelines qui cassent, les ajustements de prompts qui finissent par fonctionner, les tests d'évaluation qui ont détecté un bug avant le lancement. Cet échange granulaire et honnête est ce qui transforme des expériences individuelles en un corpus de connaissances partagées.

L'essentiel à retenir

Si vous débutez dans le développement d'IA, passez moins de temps à chercher le