Envie de vraiment travailler avec l'IA ? Commence ici

Il y a un moment précis où l'IA arrête d'être de la magie et devient un outil de travail : c'est quand tu comprends comment elle marche. Pas dans les détails d'ingénieur, juste assez pour bien t'en servir, savoir ce qu'elle te coûte et garder la main.

Comment raisonne vraiment une IA

Les tokens : l'unité de mesure cachée

Quand tu écris à une IA, elle ne lit pas des mots. Elle lit des tokens : de petits bouts de texte. Un token, ça peut être un mot entier (« maison »), un morceau de mot (« intelli » + « gence ») ou un signe de ponctuation.

Pourquoi les découper comme ça, plutôt que de raisonner par mots entiers ?

Si le modèle ne connaissait que des mots complets, le moindre mot jamais vu le bloquerait : une faute de frappe, un nom propre, un terme technique, un mot étranger. Tout ce qui n'est pas dans son vocabulaire serait un trou noir. Avec les fragments, c'est l'inverse : il reconstruit même ce qu'il n'a jamais croisé en réassemblant des morceaux qu'il connaît déjà — et c'est pour ça qu'il te comprend même quand tu écris à toute vitesse des mots qui n'ont aucun sens ! 😉

Alors autant descendre jusqu'aux lettres, une par une ?

Non, ça ne marche pas non plus : plus l'unité est petite, plus il faut de tokens pour dire la même chose — et le travail du modèle grimpe de façon explosive. Doubler les tokens ne double pas l'effort, il le fait exploser. Le token, c'est le bon compromis : assez gros pour rester efficace, assez petit pour ne pas caler devant un mot nouveau.

Dans l'IA, tout se compte en tokens — ce que tu écris, toi, et ce que répond le modèle — et c'est là-dessus qu'on calcule ce que tu paies, en entrée comme en sortie. Ce n'est pas un détail technique : c'est l'unité avec laquelle tu mesures le travail et le coût.

Le coût des modèles : pourquoi deux réponses semblables coûtent différemment

Chaque modèle a son tarif, en général affiché en coût par million de tokens. Et là, première surprise : la même question, posée à deux modèles différents, peut coûter vingt fois plus.

Les modèles les plus puissants coûtent plus cher à faire tourner, donc plus cher au token : un modèle léger te revient à quelques centimes là où un modèle haut de gamme demande quelques euros. D'où une règle pratique : tu n'as pas toujours besoin du modèle le plus puissant. Pour résumer un e-mail ou trier des demandes, le léger fait très bien le job pour une fraction du prix ; le cher, tu le gardes pour le vrai raisonnement — une analyse pointue, du code délicat, un texte qui doit être nickel. Choisir le bon modèle pour la bonne tâche, c'est déjà la moitié de la maîtrise des coûts.

Deuxième chose qui pèse sur l'addition : l'entrée et la sortie ne se paient pas pareil. Les tokens que tu envoies, toi — ton prompt, tes documents, l'historique de la conversation — c'est l'input. Ceux que le modèle écrit en réponse, c'est l'output, et ça coûte presque toujours plus cher, souvent trois ou quatre fois plus.

Ça dépend d'où va l'effort. Lire ton prompt, c'est facile : le modèle l'avale d'un coup. Écrire la réponse, c'est le vrai boulot — il sort un token à la fois, et à chaque étape il décide quel est le suivant en tenant compte de tout ce qu'il a déjà écrit. L'énergie part dans l'écriture, pas dans la lecture. Voilà pourquoi tu paies plus l'output et moins l'input.

Le contexte : la mémoire de travail du modèle

Le contexte, c'est tout ce que le modèle a sous les yeux pendant qu'il te répond : ta question, les instructions, les documents que tu lui as filés, l'échange jusqu'ici.

Deux choses à savoir. La première : le contexte a une limite, la fenêtre de contexte, elle aussi en tokens. Grande, tu peux y glisser des contrats ou des rapports entiers ; petite, tu dois faire le tri. La seconde, moins évidente : tout le contexte se paie, à chaque message. Dans une longue conversation, chaque nouvelle ligne oblige le modèle à relire tout le reste depuis le début. C'est pour ça que les chats à rallonge deviennent lents et chers : ils traînent une charge de plus en plus lourde.

Vois ça comme un bureau. Le contexte, c'est l'espace sur la table : tu y poses les documents dont tu as besoin maintenant. Encombre-le de paperasse inutile et tu travailles moins bien. Le garder dégagé — ne donner au modèle que ce qui sert — c'est une vraie compétence.

Quelle taille fait cette fenêtre ?

De plus en plus grande. À côté du nom d'un modèle, tu vois souvent un nombre du genre 1M : la fenêtre atteint un million de tokens, à peu près le maximum aujourd'hui. Ça fait des centaines de pages : en théorie, des documents entiers ou des conversations à rallonge y tiennent.

En théorie. Parce qu'avoir la place ne veut pas dire qu'il faut la remplir : plus tu charges le contexte, plus la qualité des réponses baisse. Noyé sous des milliers de lignes, le modèle a du mal à garder le fil de ce qui compte — déjà au-delà de 300 000 tokens environ, il commence à perdre en précision et à « oublier » des morceaux importants. C'est une limite d'aujourd'hui, qui s'atténuera à mesure que les modèles progressent, mais pour l'instant il faut faire avec. Le but, ce n'est pas de remplir la fenêtre : c'est de ne jamais s'approcher du fond.

En pratique, deux habitudes suffisent :

• Compacte souvent. Avance par étapes : à chaque palier, résume où tu en es, repars du résumé et laisse le reste derrière. Une conversation nettoyée tourne bien mieux qu'une qui traîne tout depuis le début. Certains outils le font tout seuls — ChatGPT et Claude gèrent le contexte en coulisses, écartant les vieux messages quand le chat s'allonge. D'autres, pensés pour qui travaille en profondeur (Claude Code, par exemple), te laissent les commandes : la compaction, c'est toi qui la lances, avec une commande du genre /compact.
• Une session par sujet. Travaux différents, chats différents. N'utilise pas le même fil pour écrire un e-mail à un client, retoucher un tableur, puis brainstormer un post : chaque sujet laisse des traces qui brouillent le suivant. Ouvrir un nouveau chat ne coûte rien, et c'est presque toujours le bon réflexe.

Modèles simples et modèles complexes : la différence qui compte

On a tendance à croire que le modèle le plus cher est forcément le meilleur. C'est plus utile de les voir comme une équipe avec des rôles différents.

Un modèle léger est rapide et économique, parfait pour les tâches bien cadrées et répétitives : extraire des données, classer, répondre à des questions de routine, sortir des premiers jets. C'est le stagiaire dégourdi : tu lui donnes une tâche claire et il l'exécute vite.

Un modèle haut de gamme est plus lent et plus cher, mais il tient le raisonnement élaboré, les nuances, les problèmes à plusieurs étages. C'est le consultant senior : tu le paies plus cher, mais tu l'appelles quand l'affaire est sérieuse.

Savoir jongler entre les deux — le léger pour le volume, le puissant pour les nœuds difficiles — c'est ce qui sépare celui qui utilise l'IA avec discernement de celui qui le fait au hasard.

Langage ou multimodal : ce que « voit » le modèle

Les premiers modèles comprenaient et produisaient uniquement du texte : ce sont les modèles de langage. Tu écris, ils écrivent.

Les modèles multimodaux gèrent plusieurs types de données à la fois : texte, images, parfois audio et vidéo. Tu lui montres la photo d'une facture et il en sort les chiffres, tu lui files la capture d'un graphique et il te le commente, tu lui donnes une image et il te dit ce qu'il y a dessus.

Une distinction utile : multimodal en entrée et en sortie. En entrée, ça veut dire que le modèle peut recevoir autre chose que du texte — photos, PDF, audio, vidéo. En sortie, qu'il peut en produire — pas seulement écrire, mais générer une image ou une voix. Les modèles haut de gamme d'aujourd'hui (GPT-5.5, Gemini 3, Claude Opus 4.7) avalent presque tout en entrée ; en sortie, les capacités varient beaucoup, alors mieux vaut vérifier au cas par cas.

Quelques sigles, utiles à déchiffrer une fois pour toutes :

• STT (Speech-To-Text) : de la voix au texte. La transcription automatique — tu parles, et ça s'affiche écrit. On le trouve aussi sous le nom d'ASR (Automatic Speech Recognition).
• TTS (Text-To-Speech) : du texte à la voix. Le chemin inverse — tu écris, et le modèle lit à voix haute.
• Text-to-Image (parfois TTI) : du texte à l'image. Tu décris ce que tu veux et le modèle le dessine — c'est le cœur d'outils comme Midjourney ou DALL·E.
• Image-to-Image (img2img) : d'une image à une image. Tu pars d'une image et tu la transformes — tu en changes le style, tu la retouches, tu l'étends au-delà des bords.

Pour toi qui décides quoi automatiser, la vraie question tient en une ligne : ton matériau de départ, c'est du texte seul, ou il y a aussi des images et des documents visuels ?

Scans, photos, PDF pleins de tableaux : il te faut un multimodal. Du texte uniquement : un modèle de langage suffit largement.

Le prompt qui fait la différence

La plupart du temps, entre un résultat médiocre et un excellent, ce n'est pas le modèle qui fait la différence, mais la façon dont tu le lui demandes.

Le prompt, c'est l'instruction que tu donnes à l'IA, et la qualité de la réponse suit celle de la demande. Un prompt vague (« écris-moi un truc sur le marketing ») donne un résultat vague. Un prompt carré — avec rôle, contexte, objectif, format et exemples — donne quelque chose d'utilisable.

Bon à savoir, surtout quand tu commences à utiliser l'IA dans tes outils et plus seulement en chat : on distingue trois types de prompt.

• System (système) : les instructions de fond — qui tu es et comment tu te comportes. Rôle du modèle, ton, règles à respecter toujours. C'est le cadre de toute la conversation, et il reste en général caché : dans une appli ou un assistant tout prêt, le system prompt a été écrit par celui qui l'a construit et tu ne le vois même pas.
• User (utilisateur) : ce que tu demandes, toi, message après message.
• Assistant (assistant) : les réponses du modèle, qui font partie du prompt elles aussi — à chaque nouveau message, il relit aussi ce qu'il a déjà dit.

Dans le chat de tous les jours, ces trois types restent en coulisses : tu écris, point. Mais dès que tu passes par une API ou que tu montes ton propre assistant, comprendre la différence est ce qui te permet de lui donner une identité stable (dans le system), séparée de chaque demande (dans le user).

Trois habitudes qui changent les résultats tout de suite :

• Sois précis sur le contexte et l'objectif. Pas « fais-moi un e-mail », mais « écris une relance à un client PME qui ne répond plus depuis deux semaines, ton cordial mais direct, 120 mots max ».
• Montre un exemple. Faire voir à quoi ressemble un bon résultat vaut mieux que mille explications.
• Itère. Le premier prompt est un brouillon : tu affines, tu ajoutes une contrainte, tu améliores pas à pas. Chaque réglage est un petit gain qui s'accumule.

Apprendre à bien prompter, ce n'est pas un tour de geek : c'est la compétence au meilleur retour sur investissement.

Les outils dont tu as besoin

Comprendre les concepts, c'est la moitié du travail ; l'autre moitié, c'est l'environnement dans lequel tu bosses. Ce ne sont pas des « trucs de programmeurs » : c'est l'établi de quiconque veut construire quelque chose de sérieux avec l'IA — scripts, intégrations, petits projets qui durent dans le temps.

Git : la machine à remonter le temps pour tes fichiers

Git suit chaque modification de tes fichiers. Chaque fois que tu enregistres un état (un commit), il en prend une photo : tu peux revenir à n'importe quelle version, voir ce qui a changé et quand, explorer des idées différentes en parallèle sans casser celle qui marche.

Vois ça comme l'historique des versions d'un document partagé, mais bien plus puissant et pour n'importe quel fichier. Le gain n'est pas seulement technique : c'est dormir tranquille, savoir que rien n'est perdu et que chaque erreur est réversible.

Mais en as-tu vraiment besoin ?

Question honnête — au début, ça peut faire peur — et la réponse dépend de ta façon de travailler. Si tu es freelance, que tu tournes à 90 % sur ton propre PC et que tu utilises Claude ou un autre agent local pour tes fichiers (projets, second cerveau, factures), Git ne te sert probablement pas : un disque synchronisé dans le cloud (Google Drive, OneDrive, Dropbox) qui garde une sauvegarde toujours à jour suffit. Simple, automatique, réglé.

Git devient indispensable dès que plus d'une paire de mains touche aux mêmes fichiers : tu bosses en équipe sur les mêmes projets — en local ou dans le cloud — et aujourd'hui, parmi les « membres de l'équipe », il y a aussi les agents.

Un exemple tiré de mon setup. Dans mon inbox arrive de tout : liens, idées, photos, notes. Mais ça entre par des portes différentes — parfois j'écris depuis les notes de l'iPhone, parfois j'envoie un audio à un agent qui le transcrit (STT) et enregistre le texte direct sur GitHub. Du coup le même dossier est touché par mon PC et par un agent qui écrit depuis le cloud, parfois à la même minute. Sans Git pour gérer ces chevauchements et les fusionner sans rien perdre, je serais coincé.

La règle pratique, donc :

• Tu bosses seul et tu débutes avec les agents locaux ?
  Un disque synchronisé en sauvegarde, c'est plus que suffisant.
• Tu as un second cerveau partagé avec tes associés, ou plusieurs sources — toi plus tes agents — qui écrivent dans les mêmes fichiers ?
  Là, Git cesse d'être une coquetterie de développeurs et devient la seule chose qui tient l'ensemble.

Un argument qui fait plaisir : Git est gratuit. Pour démarrer, tu t'appuies sur GitHub ou GitLab, dont les offres gratuites sont largement suffisantes. Et si tu as des données que tu préfères ne confier à aucun prestataire externe, Git est open source : tu montes un serveur auto-hébergé (Gitea ou GitLab CE) sur ton propre VPS et tu gardes tout chez toi. Même outil, contrôle total.

Fichiers .md (Markdown) : documenter sans effort

Le Markdown (les fichiers .md) est une façon d'écrire du texte mis en forme — titres, listes, gras, liens — avec des signes simples, sans Word et sans menus. Un # fait un titre, un tiret une liste, deux astérisques le gras.

C'est léger, lisible tel quel, ça marche partout. C'est le standard pour documenter des projets et prendre des notes structurées et — ce n'est pas un hasard — le format dans lequel on parle souvent à l'IA. Les quatre règles de base s'apprennent en dix minutes.

Il y a une raison de plus, et elle concerne l'IA : un Markdown passe bien mieux qu'un PDF. Le PDF est né pour l'impression, il est bourré d'infos de mise en page qui ne servent pas au modèle et lui encombrent le contexte ; le Markdown, c'est du texte propre. À contenu égal, il prend moins de place dans la fenêtre et laisse le modèle plus clair.

Et le plus beau : si tu laisses l'IA générer et ranger tes .md — en lui demandant de les garder compacts — c'est elle qui ajoutera les liens entre les notes (les wikilinks), les index, les renvois croisés. En pratique, elle te bâtit un petit second cerveau navigable, sans que tu mettes en page quoi que ce soit.

« Mais moi j'ai une montagne de PDF, je fais comment ? »

Ça dépend de l'usage :

• PDF du quotidien que l'IA doit relire à chaque fois (manuels, fiches, documents de référence) : convertis-les une fois en Markdown et garde-les comme version de travail. Ils entrent dans le contexte propres et légers.
• PDF d'archive dont seuls les totaux t'intéressent (relevés de compte, factures, reçus) : ne les donne pas à l'IA un par un. En fin de mois, extrais les chiffres dont tu as besoin dans un CSV ou un tableur et travaille là-dessus. Un tableau propre vaut cent PDF feuilletés un par un.

Un dernier conseil : pour lire et gérer les .md sans peine, il y a Obsidian, une appli gratuite faite exprès. Elle les affiche bien formatés, suit les liens entre notes d'un clic, et transforme un dossier de .md en une vraie archive navigable.

API et OAuth : connecter tes outils

Une API, c'est la façon dont deux logiciels s'échangent des infos : un programme envoie une requête dans un format prédéfini, l'autre répond, de manière automatique et toujours pareille. Les règles du dialogue — quelles requêtes sont admises et quelle forme prend la réponse — sont fixées par celui qui met l'API à disposition. Tu ne fais pas ce que tu veux : tu utilises seulement les opérations prévues, de la manière prévue.

Pourquoi est-ce que ça compte autant ?

Parce qu'aujourd'hui les API sont le connecteur principal entre tous tes outils, les tiens et ceux des autres. Presque chaque service sérieux — Gmail, Asana, Trello, ton logiciel de gestion, et même la banque — expose une API : c'est la porte par laquelle passent les automatisations et par où un outil parle à un autre. Et c'est aussi comme ça qu'une IA travaille dans tes outils, au lieu de rester enfermée dans son chat.

Mais pour frapper à cette porte, tu dois t'identifier, et il y a deux façons à bien distinguer :

• Clé API (API key) : un code secret que tu génères dans les réglages du service et qui dit « c'est moi ». Tu l'utilises pour tes automatisations, où tu contrôles les deux bouts. À garder en lieu sûr — plus loin, avec les fichiers .env, on voit comment.
• OAuth : le « feu vert avec poignée de main ». Au lieu de copier une clé, tu cliques sur Connecter, tu te connectes et tu autorises l'appli à entrer — sans jamais livrer ton mot de passe. C'est ce qui se passe quand tu connectes Asana ou Trello à Claude : un écran te demande la permission, tu l'accordes, et à partir de là les deux outils se parlent. L'accès, tu le révoques quand tu veux, et le mot de passe ne change jamais de mains.

Une distinction qui coûte de l'argent bien réel : abonnement ou API à l'usage ?

Utiliser Claude ou ChatGPT depuis leurs applis, avec l'abonnement mensuel fixe, c'est pratique pour le travail de tous les jours : tu paies un forfait et tu profites de l'interface prête à l'emploi.

Via API — depuis la console d'Anthropic ou la platform d'OpenAI — ça marche autrement : pas d'abonnement, tu paies à l'usage, au token (tu te souviens de l'input et de l'output ?). C'est la voie pour intégrer l'IA dans tes outils ou dans les automatisations : plus souple et plus puissant, mais attention à l'addition — avec les modèles haut de gamme, les chiffres montent vite, et la dépense, c'est toi qui la surveilles.

Pour t'orienter :

• Tu utilises Claude tous les jours et tu veux lui brancher Gmail, Asana, Drive, Calendar ?
  Abonnement + OAuth. Tu paies le forfait fixe et tu connectes tes outils d'un clic, sans toucher à une clé.
• Tu es en train de construire des agents — dans le cloud ou en local — sur des modèles OpenAI ou Anthropic ?
  Crée une clé API et ajoute-la au projet : tu accèdes à tous les modèles du fournisseur, souvent un choix plus large que ceux du forfait mensuel.

Et un outil pratique pour finir : Postman te permet d'essayer une API sans avoir encore écrit de programme. Tu remplis la requête dans une interface visuelle, tu valides, tu vois la réponse. C'est l'entraînement idéal pour comprendre comment se comporte un service avant de l'intégrer pour de vrai — sans la peur de tout casser.

Python & Cie : quand tu veux construire quelque chose à toi

Petit avertissement honnête : ici on entre dans le territoire « avancé », donc je fais court.

Envie d'aller plus loin et de te créer tes propres petits outils ?

Ne te bloque pas sur le « quel langage je choisis ? comment je développe ça ? ». Ça dépend de ce que tu veux faire, mais avec une poignée d'outils répandus et bien documentés tu fais déjà énormément.

D'abord deux mots que tu entendras partout :

• Stack : l'ensemble des outils avec lesquels tu construis un logiciel — le langage, la base de données, l'interface. « Choisir un stack », c'est décider avec quelles briques tu montes l'application.
• Frontend et backend : le frontend, c'est ce que l'utilisateur voit et touche — écrans, boutons, formulaires. Le backend, c'est le moteur derrière le rideau — logique et données, que l'utilisateur ne voit pas. Comme dans un restaurant : la salle, c'est le frontend ; la cuisine, c'est le backend.

Un stack solide et très répandu pour démarrer : Python ou Node.js (JavaScript) pour la logique, PostgreSQL comme base de données, un framework JavaScript comme React ou Next.js pour le frontend. Des outils ultra-populaires, pleins de guides et d'exemples et bien connus des IA qui t'aident à écrire le code.

Deux mots sur les langages que tu croiseras le plus souvent.

Python est la référence pour les données et l'IA : lisible presque comme de l'anglais, avec une bibliothèque pour à peu près tout, point de rencontre naturel entre l'automatisation et l'intelligence artificielle. Le jour où tu voudras faire traiter des données par une IA de façon systématique, tu le feras presque sûrement ici.

Node.js, c'est du JavaScript hors du navigateur : le même langage que les pages web, mais qui tourne sur ton ordinateur ou sur un serveur. C'est le choix naturel pour les applis web et tout ce qui vit en ligne. L'avantage : une fois JavaScript appris, tu l'utilises aussi bien pour le frontend que pour le backend.

Bash, c'est le langage du terminal, la ligne de commande : déplacer des fichiers, enchaîner des programmes, automatiser des opérations. Et il revient à la mode pour une raison précise : c'est comme ça qu'un agent installé sur ton PC parle à l'ordinateur. Quand un agent local crée un fichier, ouvre un dossier ou lance une commande, en dessous c'est du Bash. En connaître les bases sert ne serait-ce qu'à savoir ce qu'il fait à ta place.

Variables d'environnement et fichiers .env : les secrets en sécurité

Quand un programme appelle une IA via API, il doit s'identifier avec une clé secrète. Cette clé, c'est comme le code de ta carte : celui qui l'a dépense en ton nom.

La règle d'or : ne jamais écrire de clés ni de mots de passe dans le code. On les garde à part, dans des variables d'environnement — des valeurs qui vivent en dehors du programme — en général dans un fichier .env. Le programme les lit là, et ce fichier reste privé : jamais partagé, jamais publié.

C'est le coffre-fort : les valeurs importantes sont dedans, pas écrites sur le mur. C'est l'une des premières habitudes de sécurité à prendre, et l'une des plus négligées quand on débute — une clé volée, ce sont de vrais coûts sur ton compte.

Un exemple de combien c'est concret : avec l'IA, beaucoup se sont lancés à programmer sans maîtriser les bases, et il arrive qu'ils finissent par publier leurs propres clés API sur GitHub, parfois dans des dépôts publics. L'ennui, c'est qu'il y a déjà des gens qui passent ces dépôts au peigne fin exprès, à la chasse aux clés à exploiter gratos — sur le dos du malheureux.

Un peu de documentation : le cadeau que tu te fais à toi-même

Enfin, l'habitude la plus sous-estimée : noter deux lignes sur ce que fait une chose et pourquoi. Un fichier de notes, un mot sur la raison d'un choix.

Pas besoin d'un manuel. Juste ce minimum qui permet à toi-dans-six-mois — qui auras tout oublié — d'y remettre les mains en cinq minutes au lieu d'un après-midi. La documentation, c'est une lettre à ton futur toi, et ton futur toi te remerciera à chaque fois.

Deux façons concrètes de ne pas la laisser au hasard :

• Si tu utilises Git, appuie-toi sur les issues : des fiches intégrées au dépôt où tu gardes la trace des choses à faire, des bugs, des idées à ne pas perdre. Elles restent liées au projet et à son historique, si bien que la to-do list vit juste à côté du travail au lieu d'être éparpillée à dix endroits.
• Si tu n'utilises pas Git, demande à ton agent local de tenir la doc en ordre : des fichiers d'index qui servent de carte, des fichiers de session qui consignent ce que tu as fait et quand. Tu le configures une fois, et c'est lui qui s'en occupe.

Le tableau complet

D'un côté, tu as compris comment raisonne une IA : les tokens avec lesquels elle mesure — et fait payer — tout, input et output compris ; le coût qui change énormément entre un modèle léger et un haut de gamme ; le contexte à garder propre comme un bureau, à compacter souvent et à ne jamais remplir jusqu'au fond ; la différence entre langage et multimodal ; et les prompts — avec les rôles system, user et assistant — comme levier principal pour de meilleurs résultats.

De l'autre, tu as l'établi : Git pour ne rien perdre (quand tu en as vraiment besoin), le Markdown pour documenter et mieux dialoguer avec l'IA, les API avec clé ou OAuth pour connecter tes outils, le choix entre abonnement et usage, Python, Node et Bash pour te construire quelque chose à toi, les fichiers .env pour les secrets, et un peu de documentation pour le toi de demain.

Aucun de ces concepts ne demande un doctorat. Il suffit de les voir une fois clairement — et ensuite ils deviennent le langage commun avec lequel prendre l'IA en main et l'utiliser avec discernement.