Un modèle mental clair pour comprendre comment l'IA génère du code et des décisions dans les apps — jetons, fenêtre de contexte, outils, tests — avec limites et conseils pratiques de prompting.
Quand on dit « l'IA pense », on entend généralement : elle comprend votre question, raisonne et décide d'une réponse.
Pour les modèles de texte modernes (LLM), un modèle mental plus utile est plus simple : le modèle prédit le texte qui doit venir ensuite.
Ça peut paraître décevant — jusqu'à ce qu'on réalise jusqu'où peut aller ce « texte suivant ». Si le modèle a appris suffisamment de motifs pendant l'entraînement, prédire le mot suivant (puis le suivant, puis le suivant) peut produire des explications, des plans, du code, des résumés et même des données structurées que votre app peut utiliser.
Vous n'avez pas besoin d'apprendre les mathématiques sous-jacentes pour créer de bonnes fonctionnalités IA. Ce dont vous avez besoin, c'est d'une manière pratique d'anticiper le comportement :
Cet article est ce type de modèle : pas de la hype, pas un article technique profond — juste les concepts qui vous aident à concevoir des expériences produit fiables.
Pour un créateur d'apps, la « pensée » du modèle, c'est le texte qu'il génère en réponse à l'entrée que vous fournissez (votre prompt, les messages utilisateur, les règles système et tout contenu récupéré). Le modèle ne vérifie pas les faits par défaut, ne navigue pas sur le web et ne « sait » pas ce que contient votre base de données sauf si vous lui transmettez cette information.
Fixez donc les attentes : les LLM sont extrêmement utiles pour rédiger, transformer et classer du texte, et pour générer des sorties de type code. Ils ne sont pas des moteurs magiques de vérité.
Nous allons découper le modèle mental en quelques parties :
Avec ces idées, vous pouvez concevoir des prompts, des UI et des garanties qui rendent les fonctionnalités IA cohérentes et dignes de confiance.
Quand on dit qu'une IA « pense », il est facile d'imaginer qu'elle raisonne comme une personne. Un modèle mental plus utile est plus simple : elle fait de l'autocomplétion extrêmement rapide — une petite unité à la fois.
Un jeton est un fragment de texte avec lequel le modèle travaille. Parfois c'est un mot entier (« pomme »), parfois une partie de mot (« ap » + « ple »), parfois de la ponctuation, parfois même un espace. Le découpage exact dépend du tokenizer du modèle, mais la conclusion est : le modèle ne traite pas le texte comme de belles phrases — il traite des jetons.
La boucle de base du modèle est :
C'est tout. Chaque paragraphe, liste à puces et chaîne de « raisonnement » que vous voyez est construit en répétant cette prédiction du prochain jeton de nombreuses fois.
Parce que le modèle a vu d'énormes quantités de texte pendant l'entraînement, il apprend des motifs comme la façon dont les explications s'enchaînent, ce qu'un e‑mail poli ressemble, ou comment une correction de bug est décrite habituellement. Quand vous posez une question, il génère une réponse qui correspond aux motifs qu'il a appris et au contexte que vous avez fourni.
C'est pourquoi il peut sembler confiant et cohérent même lorsqu'il se trompe : il optimise pour le texte le plus plausible à produire, pas pour vérifier la réalité.
Le code n'est pas spécial pour le modèle. JavaScript, SQL, JSON et les messages d'erreur sont tous des séquences de jetons. Le modèle peut produire du code utile parce qu'il a appris des motifs de codage courants, pas parce qu'il « comprend » votre application comme un ingénieur le ferait.
Quand on demande « d'où vient cette réponse ? », le modèle a appris des motifs à partir d'un grand nombre d'exemples, et il recombine ensuite ces motifs pour prédire le texte suivant.
Pendant l'entraînement, le modèle voit de nombreux extraits de texte (livres, articles, code, documentation, Q&A, et plus). Il s'exerce à une tâche simple : étant donné un texte, prédire le prochain jeton. Quand il se trompe, l'entraînement ajuste légèrement les paramètres internes pour rendre la bonne prédiction un peu plus probable la fois suivante.
Au fil du temps, ces ajustements s'accumulent. Le modèle en vient à encoder des relations telles que :
Parce qu'il apprend des régularités statistiques — pas un script fixe — il peut combiner des motifs de nouvelles façons. S'il a vu beaucoup d'exemples d'« expliquer un concept » et d'exemples de « votre scénario d'app », il peut souvent fusionner ça en une réponse adaptée.
C'est pourquoi un LLM peut rédiger un e‑mail d'onboarding plausible pour un produit de niche, ou adapter une explication d'intégration d'API à une pile spécifique. Il ne récupère pas un paragraphe stocké ; il génère une nouvelle séquence qui correspond aux motifs appris.
Même si des données d'entraînement contenaient un fait spécifique (par exemple une offre tarifaire ou une politique interne), il ne faut pas supposer que le modèle peut « le consulter » de façon fiable. L'entraînement ressemble plus à une compression : beaucoup d'exemples sont distillés en poids qui influencent les prédictions futures.
Cela signifie que le modèle peut sembler sûr concernant des détails qu'il devine en se basant sur ce qui apparaît habituellement dans des contextes similaires.
L'apprentissage par motifs est puissant pour produire du texte fluide et pertinent, mais la fluidité n'est pas la vérité. Le modèle peut :
Pour les créateurs d'apps, la leçon clé est : les réponses d'un LLM proviennent généralement de motifs appris, pas de faits vérifiés. Si l'exactitude est importante, il faudra ancrer la sortie avec vos propres données et vérifications (nous y reviendrons).
Quand un LLM écrit une réponse, il ne tire pas une « phrase correcte » unique d'une base. À chaque étape, il prédit une distribution de jetons possibles, chacun avec une probabilité.
Si le modèle choisissait toujours le jeton unique le plus probable, les réponses seraient très constantes — mais aussi répétitives et parfois rigides. La plupart des systèmes échantillonnent à partir des probabilités, ce qui introduit un hasard contrôlé.
Deux réglages courants façonnent la variété des sorties :
Si vous construisez une app, ces réglages sont moins une question d'« être créatif » au sens artistique que de choisir entre :
Parce que le modèle optimise pour du texte plausible, il peut produire des affirmations qui sonnent certaines — même si la revendication sous-jacente est incorrecte ou incomplète. Le ton confiant n'est pas une preuve. C'est pourquoi les apps ont souvent besoin d'ancrage (récupération) ou d'étapes de vérification pour les tâches factuelles.
Demandez au LLM : « Écris une fonction JavaScript qui supprime les doublons d'un tableau. » Vous pouvez obtenir l'une de ces réponses, toutes valides :
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicite
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
Différents choix d'échantillonnage donnent des styles différents (concise vs explicite), des compromis différents (performance, lisibilité), et même des comportements différents sur les cas limites — tout cela sans que le modèle « change d'avis » : il choisit juste parmi plusieurs continuations à haute probabilité.
Quand on dit qu'un modèle « se souvient » d'une conversation, il a en réalité un contexte : le texte qu'il peut voir maintenant — votre dernier message, les instructions système, et la portion de la conversation antérieure qui tient encore.
La fenêtre de contexte est une limite fixe sur la quantité de texte que le modèle peut considérer en une fois. Quand la conversation devient assez longue, les parties anciennes tombent hors de cette fenêtre et disparaissent de la vue du modèle.
C'est pourquoi vous verrez parfois des comportements comme :
Si vous empilez des messages dans un fil, vous vous battez pour de l'espace limité. Les contraintes importantes sont repoussées par les échanges récents. Sans résumé, le modèle doit inférer ce qui importe à partir de ce qui reste visible — et il peut sembler sûr tout en manquant discrètement des détails clés.
Une solution pratique est de résumer périodiquement : reformulez l'objectif, les décisions et les contraintes dans un bloc compact, puis continuez. Dans les apps, cela s'implémente souvent comme un « résumé de conversation » automatique qui est injecté dans le prompt.
Les modèles suivent mieux les instructions qui sont proches de la sortie qu'ils vont générer. Donc si vous avez des règles absolues (format, ton, cas limites), placez-les près de la fin du prompt — juste avant « Produisez la réponse. »
Si vous construisez une app, traitez cela comme du design d'interface : décidez ce qui doit rester dans le contexte (exigences, préférences utilisateur, schéma) et assurez-vous que c'est toujours inclus — soit en tronquant l'historique, soit en ajoutant un résumé serré. Pour plus sur la structuration des prompts, voir /blog/prompting-as-interface-design.
Les LLM excellent à produire un texte qui sonne comme la réponse d'un développeur compétent. Mais « sonner juste » n'est pas identique à « être juste ». Le modèle prédit des jetons plausibles, il ne vérifie pas la sortie contre votre codebase, vos dépendances ou le monde réel.
Si le modèle suggère un correctif, un refactor ou une nouvelle fonction, ce n'est toujours que du texte. Il n'exécute pas votre app, n'importe pas vos packages, n'appelle pas votre API ni ne compile votre projet à moins que vous le reliiez explicitement à un outil capable de le faire (par exemple un runner de tests, un linter ou une étape de build).
C'est le contraste clé :
Quand l'IA se trompe, c'est souvent de façon prévisible :
Ces erreurs peuvent être difficiles à repérer parce que l'explication autour est généralement cohérente.
Considérez la sortie IA comme un brouillon rapide d'un collègue qui n'a pas exécuté le projet localement. La confiance augmente fortement après que vous :
Si les tests échouent, supposez que la réponse du modèle est un point de départ, pas une correction finale.
Un modèle de langage est excellent pour proposer ce qui pourrait fonctionner — mais seul il produit encore du texte. Les outils permettent à une app pilotée par IA de transformer ces propositions en actions vérifiées : exécuter du code, interroger une base, récupérer la doc ou appeler une API.
Dans les workflows de construction d'apps, les outils prennent souvent la forme :
Le changement important est que le modèle ne joue plus à faire semblant de connaître le résultat — il peut vérifier.
Un modèle mental utile est :
C'est ainsi que l'on réduit la conjecture. Si le linter signale un import inutilisé, le modèle met à jour le code. Si les tests unitaires échouent, il itère jusqu'à ce qu'ils passent (ou explique pourquoi il n'y arrive pas).
eslint/ruff/prettier pour confirmer le style et détecter les problèmes.Les outils sont puissants — et potentiellement dangereux. Appliquez le principe du moindre privilège :
Les outils ne rendent pas le modèle « plus intelligent », mais ils rendent l'IA de votre app plus ancrée — parce qu'elle peut vérifier, pas seulement narrer.
Un modèle de langage est excellent pour écrire, résumer et raisonner sur le texte qu'il peut « voir ». Mais il ne connaît pas automatiquement vos dernières évolutions produit, vos politiques internes ou les détails d'un compte client. La génération augmentée par récupération (RAG) est une solution simple : récupérez d'abord les faits les plus pertinents, puis demandez au modèle d'écrire en utilisant ces faits.
Pensez à RAG comme à une IA « à livre ouvert ». Au lieu de demander au modèle de répondre depuis sa mémoire, votre app récupère rapidement une poignée de passages pertinents depuis des sources de confiance et les ajoute au prompt. Le modèle génère alors une réponse ancrée dans ce matériau fourni.
RAG est un bon choix par défaut quand l'exactitude dépend d'informations extérieures au modèle :
Si la valeur de votre app dépend de « la bonne réponse pour notre business », RAG est généralement préférable à espérer que le modèle devine.
RAG n'est aussi bon que ce qu'il récupère. Si l'étape de recherche renvoie des passages obsolètes, non pertinents ou incomplets, le modèle peut produire une réponse fausse — maintenant « ancrée » dans une mauvaise source. En pratique, améliorer la qualité de la récupération (chunking, métadonnées, fraîcheur et classement) améliore souvent la précision plus que de toucher aux prompts.
Un « agent » est simplement un LLM qui tourne en boucle : il établit un plan, exécute une étape, regarde le résultat et décide de la suite. Au lieu de répondre une fois, il itère jusqu'à atteindre un objectif.
Un modèle mental utile est :
Planifier → Agir → Vérifier → Réviser
Cette boucle transforme un prompt unique en un petit workflow. C'est aussi pourquoi les agents peuvent sembler plus « autonomes » que le chat : le modèle ne produit pas seulement du texte, il choisit des actions et les enchaîne.
Les agents ont besoin de règles claires pour savoir quand s'arrêter. Conditions d'arrêt courantes :
Les garde‑fous sont les contraintes qui gardent la boucle sûre et prévisible : outils autorisés, sources de données permises, étapes d'approbation (humain dans la boucle) et formats de sortie.
Parce qu'un agent peut toujours proposer « une étape de plus », vous devez concevoir pour l'échec. Sans budgets, timeouts et limites d'étapes, un agent peut spiraler en actions répétitives (« réessayer avec une requête légèrement différente ») ou générer des coûts importants.
Defaults pratiques : plafonner les itérations, consigner chaque action, exiger la validation des résultats d'outil, et échouer proprement en renvoyant une réponse partielle plus ce qu'il a essayé. C'est souvent une meilleure conception produit que de laisser l'agent boucler indéfiniment.
Si vous bâtissez avec une plateforme orientée code‑vibe comme Koder.ai, ce modèle mental « agent + outils » est particulièrement pratique. Vous ne vous contentez pas de chatter pour des suggestions — vous utilisez un workflow où l'assistant peut aider à planifier des fonctionnalités, générer des composants React/Go/PostgreSQL ou Flutter, et itérer avec des points de contrôle (par exemple snapshots et rollback) pour avancer vite sans perdre le contrôle des changements.
Quand vous placez un LLM derrière une fonctionnalité d'app, votre prompt n'est plus « juste du texte ». C'est le contrat d'interface entre votre produit et le modèle : ce que le modèle doit faire, ce qu'il est autorisé à utiliser, et comment il doit répondre pour que votre code puisse consommer la sortie de façon fiable.
Une bonne mentalité est de traiter les prompts comme des formulaires UI. Les bons formulaires réduisent l'ambiguïté, contraignent les choix et rendent l'étape suivante évidente. Les bons prompts font pareil.
Avant de déployer un prompt, assurez‑vous qu'il indique clairement :
Les modèles suivent des motifs. Une manière efficace d'« enseigner » le motif souhaité est d'inclure un exemple d'entrée et un exemple de sortie (surtout si la tâche a des cas limites).
Même un seul exemple peut réduire les allers‑retours et empêcher le modèle d'inventer un format que votre UI ne peut pas afficher.
Si un autre système va lire la réponse, structurez‑la. Demandez du JSON, un tableau ou des listes strictes.
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
Cela transforme le « prompting » en design d'interface prévisible.
Ajoutez une règle explicite comme : « Si des exigences clés manquent, posez des questions clarificatrices avant de répondre. »
Cette simple ligne peut empêcher des sorties faussement assurées — car le modèle est alors autorisé (et attendu) à marquer une pause et demander les champs manquants au lieu de deviner.
En pratique, les prompts les plus fiables correspondent à la façon dont votre produit est construit et déployé. Par exemple, si votre plateforme supporte planifier d'abord, puis générer des changements, puis exporter du code ou déployer, vous pouvez refléter cela dans le contrat de prompt (plan → produire diff/étapes → confirmer → appliquer). Le « planning mode » de Koder.ai est un bon exemple de comment transformer le processus en phases explicites peut réduire la dérive et aider les équipes à revoir les changements avant publication.
La confiance ne vient pas d'un modèle qui « sonne sûr ». Elle vient du fait que la sortie IA est traitée comme une dépendance produit : mesurée, surveillée et contrainte.
Commencez par un petit ensemble de tâches réelles que votre app doit bien accomplir. Transformez‑les ensuite en vérifications reproductibles :
Au lieu de demander « Est‑ce bon ? », suivez « À quelle fréquence ça passe ? » Métriques utiles :
Quand quelque chose casse, vous devez pouvoir le rejouer. Journalisez (avec redaction appropriée) :
Cela rend le débogage pratique et vous aide à répondre : « Est‑ce le modèle qui a changé, ou nos données/outils ? »
Quelques règles par défaut évitent des incidents courants :
Cela signifie généralement que le modèle peut produire un texte cohérent et orienté vers un objectif qui donne l'impression de comprendre et de raisonner. En pratique, un grand modèle de langue (LLM) effectue de la prédiction du prochain jeton : il génère la continuation la plus probable à partir de votre prompt, des instructions système et du contexte fourni.
Pour les concepteurs d'apps, l'idée utile est que la « pensée » est le comportement de sortie que vous pouvez façonner et contraindre — pas une garantie interne de vérité.
Un jeton est un fragment de texte que le modèle traite et génère (un mot entier, une partie de mot, une ponctuation ou un espace). Parce que les modèles opèrent sur des jetons, et non sur des « phrases » complètes, les coûts, les limites et les troncations sont tous mesurés en jetons.
Concrètement :
Parce que la génération est probabiliste. À chaque étape, le modèle attribue des probabilités à de nombreux jetons possibles, et la plupart des systèmes échantillonnent à partir de cette distribution au lieu de toujours choisir l'option la plus probable.
Pour rendre les sorties plus reproductibles :
Les LLM optimisent la production d'un texte plausible, pas la vérification des faits. Ils peuvent paraître catégoriques parce qu'une formulation assurée est un motif fréquent dans les données d'entraînement, même lorsque l'affirmation sous-jacente est une supposition.
En conception produit, considérez la fluidité comme une « belle formulation », pas comme une « garantie de justesse », et ajoutez des vérifications (récupération, outils, tests, approbations) lorsque la justesse importe.
La fenêtre de contexte est la quantité maximale de texte que le modèle peut considérer à la fois (instructions système, historique de conversation, extraits récupérés, etc.). Quand le fil devient trop long, les informations anciennes sortent de la fenêtre et le modèle ne peut plus les « voir ».
Atténuations :
Pas automatiquement. Par défaut, le modèle ne navigue pas sur le web, ne lit pas votre base de données et n'exécute pas votre code. Il n'a accès qu'à ce que vous incluez dans le prompt et aux outils que vous connectez explicitement.
Si la réponse dépend d'informations internes ou récentes, faites-les passer via la récupération (RAG) ou un appel d'outil plutôt que d'« insister » auprès du modèle.
Utilisez des outils lorsque vous avez besoin de résultats vérifiés ou d'actions réelles plutôt que d'un texte plausible. Exemples courants :
Un bon schéma est proposer → vérifier → ajuster, où le modèle itère en fonction des sorties des outils.
RAG (Retrieval-Augmented Generation) est l'« IA à livre ouvert » : votre app récupère des extraits pertinents depuis des sources fiables (docs, tickets, politiques) et les inclut dans le prompt pour que le modèle réponde en s'appuyant sur ces faits.
Utilisez RAG quand :
Le principal défaut est une mauvaise récupération : améliorer la recherche, le découpage en chunks et la fraîcheur bat souvent les ajustements de prompt.
Un agent est un LLM exécutant une boucle multi‑étapes (planifier, agir, vérifier, réviser) souvent en utilisant des outils. Il est utile pour des workflows comme « trouver l'info → rédiger → valider → envoyer ».
Pour garder les agents sûrs et prévisibles :
Traitez les prompts comme un contrat d'interface : définissez l'objectif, les entrées, les contraintes et le format de sortie pour que votre app puisse consommer les résultats de manière fiable.
Constructions pratiques pour la confiance :