“Un outil électrique a besoin d'un établi. Le modèle, c'est la lame ; le système, c'est tout ce qui garde vos doigts intacts.”
Modèle mince, système épais
Une démo, c'est un modèle avec un prompt. Un produit, c'est un modèle enveloppé de récupération, d'outils, de garde-fous, de chemins de repli, de journalisation et d'évaluations. Le modèle représente peut-être 5 % du code et 90 % de la magie — mais les 95 % restants du code, c'est ce qui rend cette magie assez fiable pour facturer.
Le changement de perspective le plus utile pour construire avec l'IA : arrêtez d'essayer d'améliorer le modèle, et commencez à améliorer le système autour de lui. Vous ne pouvez généralement pas réentraîner le modèle. Vous pouvez toujours améliorer ce que vous lui donnez à manger, ce que vous lui laissez toucher, et comment vous vérifiez son travail.
Les quatre rôles du système
Tout ce que vous construisez autour du modèle accomplit l'un de quatre rôles : acheminer les bonnes informations (récupération), donner au modèle de vraies capacités (outils), empêcher les entrées et sorties nuisibles (garde-fous), et savoir si quoi que ce soit fonctionne (évaluations). Le reste de ce cours consacre un chapitre à chaque rôle, plus comment livrer et opérer l'ensemble.
Noyau probabiliste, enveloppe déterministe
Le modèle est probabiliste : la même entrée peut produire des sorties différentes, et il n'a aucune notion de « correct ». Votre système doit être aussi déterministe que possible partout ailleurs. Analysez la sortie du modèle selon un schéma strict. Validez-la. Si elle échoue, réessayez ou repliez-vous — ne transmettez pas en aval une sortie non validée en espérant que tout ira bien.
Le patron qui fonctionne en production : traitez chaque appel au modèle comme un appel réseau vers un tiers peu fiable. Il peut être lent, faux, malformé ou hors service. Enveloppez-le en conséquence — délais d'attente, réessais, validation de schéma, chemin de repli — exactement comme vous le feriez pour n'importe quelle dépendance capricieuse.
Commencez par ce qui coûte le moins
Il existe un ordre naturel d'escalade, du moins coûteux au plus coûteux. Essayez d'abord un meilleur prompt. Puis ajoutez des exemples. Puis ajoutez la récupération. Puis ajoutez des outils. Ce n'est qu'après l'échec de tout cela que vous devriez envisager l'ajustement fin — c'est le levier le plus coûteux, et celui que la plupart des équipes actionnent trop tôt.
- Prompt — quelques minutes, gratuit. Essayez toujours ça en premier.
- Exemples en quelques tirs — quelques minutes, presque gratuit.
- Récupération (RAG) — quelques jours, coût modéré. La bonne réponse à « il ne connaît pas nos données ».
- Outils — quelques jours, coût modéré. La bonne réponse à « il ne peut pas faire nos tâches ».
- Ajustement fin — plusieurs semaines, coûteux. Le dernier recours, pas le premier réflexe.
En une ligne chacun
- Le modèle est un composant, pas le produit. Le système autour est la source de la fiabilité.
- Gardez la partie probabiliste petite et l'enveloppe déterministe large : validez chaque sortie contre un schéma.
- Traitez les appels au modèle comme des appels réseau capricieux — délais d'attente, réessais, replis.
- Escaladez du moins coûteux au plus coûteux : prompt → exemples → récupération → outils → ajustement fin.
Où aller ensuite