C'est quoi les données d'entraînement, et pourquoi elles décident de tout ?

La réponse en trois lignes

Expliqué à un enfant de 5 ans

Imaginez un cuisinier remarquable. Vingt ans de métier, la main sûre, jamais un plat raté.

Mais il n'a cuisiné qu'une seule cuisine. C'est celle de sa région, celle qu'il a goûtée tous les jours depuis l'enfance. Commandez-lui n'importe quel plat de chez lui : il est parfait, et il l'est sans effort.

Maintenant commandez-lui un plat qu'il n'a jamais goûté. Il ne va pas refuser. Il va le faire — avec les ingrédients qu'il connaît, les gestes qu'il a toujours faits, et l'idée qu'il s'en fait d'après le nom. Ce qui arrive à table a l'allure d'un plat réussi. Ce n'en est pas un.

Il n'est pas mauvais. Il n'est pas menteur. Il n'a simplement jamais goûté ce plat-là, et rien dans son geste ne le trahit.

Une IA, c'est exactement ce cuisinier. Ce qu'elle a beaucoup vu, elle le fait très bien. Ce qu'elle n'a jamais vu, elle le fabrique à partir de ce qui lui ressemble le plus. Et à table — c'est-à-dire dans la réponse que vous lisez — rien ne distingue les deux.

Ce que ça veut dire, un peu plus précisément

Elle n'a pas de connaissances, elle a des souvenirs d'exemples. C'est la phrase à retenir. Une IA ne « sait » pas ce qu'est une facture : elle en a vu des millions, et elle en a tiré des habitudes. La différence ne se voit jamais tant que les cas restent ordinaires. Elle éclate au premier cas particulier.

Ce qui est rare dans les exemples est fragile dans la réponse. Une pratique répandue est solide, un usage local ne l'est pas. C'est la même mécanique que l'hallucination, vue depuis l'autre bout : ce n'est pas que le programme invente pour le plaisir, c'est qu'on lui demande quelque chose qui n'était pas dans ce qu'il a vu.

Les exemples emportent leurs travers avec eux. Si les cas passés privilégiaient un certain type de client, un certain vocabulaire, une certaine façon de faire, l'IA les reproduira — sans le signaler, et avec la même assurance que le reste. On appelle ça un biais ; ce n'est pas une opinion de la machine, c'est la moyenne de ce qu'on lui a montré.

Ce qu'elle a vu s'arrête à une date. Un modèle a été entraîné à un moment donné, et le monde a continué sans lui. Un changement de règle, un nouveau tarif, un produit sorti après : il n'en sait rien, et il répondra quand même.

La quantité ne rattrape pas la qualité. Dix mille exemples désordonnés apprennent le désordre. Deux cents exemples propres et représentatifs valent mieux — et ça, c'est une bonne nouvelle pour une entreprise, parce que deux cents exemples, vous les avez déjà.

La question qui vous concerne vraiment : vos données

C'est ici que se joue la seule chose importante pour vous, et c'est la question la mieux cachée de tout le sujet. Quand on vous dit « l'outil apprend de vos données », cette phrase recouvre deux réalités qui n'ont rien à voir.

Premier cas : on vous donne vos documents au moment de la question. Vous joignez un contrat, un fichier, vingt exemples de classements passés. L'outil les lit pour répondre, puis l'échange se termine. Vos données ne sont pas entrées dans le modèle : elles ont servi de pièce jointe. Elles restent chez vous, vous pouvez arrêter demain, et rien n'est parti nulle part durablement.

Second cas : on s'en sert pour entraîner le modèle. Là, vos données sont absorbées. Elles ont contribué à ce que le modèle est devenu, et on ne les en retire pas — pas plus qu'on ne retire un ingrédient d'un plat déjà cuit. Si le modèle sert aussi à d'autres, ce que vous avez fourni participe à ce qu'il leur répond.

Neuf fois sur dix, ce dont vous avez besoin est le premier cas. Il coûte moins cher, il donne un meilleur résultat plus vite, il se change en cinq minutes le jour où votre façon de travailler évolue, et il ne pose aucune question difficile sur vos données.

Alors posez la question, et posez-la par écrit :

« Mes données servent-elles à répondre à mes questions, ou à entraîner votre modèle ? »

Un fournisseur sérieux répond en une phrase et vous l'écrit dans le contrat. Une réponse floue à cette question-là est le seul signal d'alarme dont vous avez besoin.

Concrètement, chez vous

Prenons le tri des demandes qui arrivent, parce que tout le monde en a et que tout le monde le fait à la main.

Sans rien lui donner, un outil range vos demandes dans des catégories générales : « demande générale », « question technique », « autre ». C'est poli, et ça ne sert à rien : ce ne sont pas vos catégories. Sur dix demandes, quatre atterrissent au mauvais endroit — et une demande mal rangée est une demande perdue.

Maintenant, donnez-lui vingt de vos propres classements passés. Vingt vraies demandes, avec la catégorie que vous leur aviez donnée. Pas de projet, pas d'entraînement, pas de facture supplémentaire : vingt exemples, joints à la question.

Le résultat change de nature. Il reprend vos catégories, avec vos mots — « à redevisser », « pièce en rupture », « retard de livraison » — parce qu'il a vu comment vous, vous rangez. Une erreur sur dix au lieu de quatre. Et les cas dont il n'est pas sûr vous reviennent au lieu d'être rangés au hasard.

Le travail utile n'a pas été technique. Il a été de choisir les vingt bons exemples : ceux qui couvrent les cas courants et deux ou trois cas tordus. C'est une heure de votre temps, une seule fois, et c'est le meilleur investissement du chantier.

Et vos données n'ont pas quitté votre maison. Elles ont servi d'exemple, le temps d'une question.

Ce que les données d'entraînement ne peuvent pas faire

Elles ne rendent pas une IA fiable sur commande. Plus d'exemples réduisent les erreurs, ils ne les suppriment pas. Le point d'arrêt humain reste nécessaire là où l'erreur coûte cher, quel que soit le nombre d'exemples.

Elles ne remplacent pas une règle claire. Si vous ne savez pas vous-même comment ranger un cas, vos exemples se contrediront, et l'IA apprendra la contradiction. C'est le même prérequis que pour une automatisation : la mise au clair vient avant, et c'est la moitié du résultat.

Elles ne se donnent pas une fois pour toutes. Vos catégories bougent, vos produits changent, vos clients aussi. Des exemples de l'an dernier apprennent l'an dernier. C'est une demi-heure d'entretien de temps en temps, pas un projet à refaire.

Elles ne justifient pas de livrer des données personnelles. Un exemple sert à montrer une forme, pas à transporter le nom d'un client. Avant de donner vos vingt exemples, retirez ce qui identifie les gens : ça ne coûte presque rien et ça change tout.

Attention à ce qu'on vous vend sous ce mot

Méfiez-vous du « modèle entraîné sur des millions de documents ». Des millions de quoi, et ressemblant en quoi aux vôtres ? Un modèle nourri de documents d'un autre secteur lira les vôtres comme le cuisinier prépare un plat qu'il n'a jamais goûté. Le volume n'est pas un argument ; la ressemblance, si.

Méfiez-vous de « on va entraîner un modèle sur vos données ». C'est la proposition la plus chère et, neuf fois sur dix, la moins utile. Demandez pourquoi des exemples donnés au moment de la question ne suffiraient pas. Si la réponse n'est pas immédiate et précise, elle n'existe pas.

Méfiez-vous de l'absence de cas ratés. Quiconque a vraiment travaillé sur vos données sait où le résultat se dégrade, et peut vous le montrer. Un fournisseur qui n'a aucun mauvais exemple à vous présenter n'a pas encore regardé.

Méfiez-vous du silence sur le devenir de vos fichiers. Où sont-ils stockés, combien de temps, qui peut les lire, que se passe-t-il si vous arrêtez. Quatre questions, quatre réponses, par écrit. Ce n'est pas de la méfiance, c'est le minimum d'un contrat.

Et posez celle-ci, qui résume tout le reste :

« Montrez-moi dix exemples de ce que le modèle a vu qui ressemblent à mes documents. »

S'il n'y en a aucun, l'outil ne connaît pas votre métier. Il connaît celui de quelqu'un d'autre.