Au-delà du simple perroquet qui complète les phrases ? Une explication de l’émergence

Malgré tous les problèmes qu’elles engendrent, les attentes démesurées et les conséquences des fake news, les intelligences artificielles restent de bons outils qui évoluent à une rapidité folle.

Il suffit de voir les premiers LLM (grands modèles de langage), qui pensaient que les vaches pondaient des œufs, et les premières vidéos générées. Aujourd’hui, il est devenu bien plus compliqué de distinguer le vrai du généré.

Vous pouvez faire le test sur sightengine.com/ia-ou-pas pour être un peu surpris. Même avec l’habitude, personne n’atteint 100 % de réussite.

Je suis en train de lire pas mal d’articles et de regarder pas mal de vidéos pour réellement comprendre comment ça marche (je construis un outil pédagogique en parallèle pour expliquer tout ça).

Et dans tout ce que je lis, il y a un phénomène qui me fascine : les aptitudes émergentes.

De quoi on parle ?

Des capacités qui apparaissent d’un coup, à partir d’une certaine taille de modèle, sans que personne les ait programmées ni même anticipées. Le modèle ne sait pas faire, puis d’un coup … il sait faire.

Ce qui m’a le plus surpris, c’est que même les équipes qui construisent ces systèmes admettent que, lors de l’entraînement d’une grande IA, on ne sait pas à l’avance la liste de ce qu’elle saura faire à la fin. On connaît le coût, la durée, le niveau de fluidité attendu. Mais la question « saura-t-elle résoudre un problème en plusieurs étapes ? » n’a pas de réponse calculable avant d’avoir essayé. On découvre après coup.

Petit rappel de ce dont une IA est faite

Un « neurone » artificiel ne fait rien d’impressionnant. Il reçoit des nombres, les multiplie par un « poids » (un chiffre dans un tableau), additionne le tout, et applique une petite transformation. C’est tout. Un neurone seul est aussi intéressant qu’une calculatrice à une opération.

Une grande IA en contient des milliards, organisés en couches successives. Et c’est là que ça devient intéressant : le comportement du tout ne ressemble à rien de ce que fait chaque partie.

Une image pour fixer les idées

L’analogie des fourmis : une fourmi seule suit trois ou quatre règles chimiques simples. Mais cent mille fourmis bâtissent une fourmilière ventilée, avec des greniers et des pouponnières. Personne n’a l’architecture en tête. Elle émerge de l’interaction.

L’analogie de l’eau : une seule molécule d’eau ne montre rien, mais avec des milliards de molécules on voit de l’eau qui coule, se transforme en glace, s’évapore.

Dans les années 1970, le physicien Philip Anderson publie More Is Different : quand un système grossit, des propriétés réellement nouvelles apparaissent, qu’on ne peut pas deviner en examinant l’échelle inférieure.

En 1982, John Hopfield applique cette idée aux réseaux de neurones : des capacités utiles peuvent surgir comme propriétés collectives d’un grand nombre d’éléments simples. L’intuition fondatrice était posée bien avant ChatGPT.

Le chiffre qui a lancé le débat

En 2022, une équipe de chercheurs teste des IA de tailles croissantes sur une tâche simple : additionner deux nombres de trois chiffres.

Une précision importante

Quand vous demandez à l’IA de faire des calculs aujourd’hui, elle utilise des calculatrices externes. Là, on parle d’autre chose : ce que le réseau de neurones sait faire tout seul, sans outil externe, rien d’autre que les poids appris en lisant des montagnes de texte.

On écrit « 347 + 128 = » et on regarde ce que le modèle complète, comme il complèterait n’importe quelle phrase avec des mots.

Les résultats

Taille du modèleRéussiteVerdict
6 milliards de paramètres1 %Échec total
13 milliards8 %Échec quasi total
175 milliards80 %Ça marche

Regardez bien ces trois lignes. Entre le deuxième et le troisième modèle, rien n’a changé dans la méthode : même type d’architecture, même genre de données, même objectif d’entraînement. Seule la taille a augmenté. Et la capacité est passée de « inexistante » à « fiable ».

En parallèle, la mesure globale de qualité du modèle (à quel point il prédit bien le mot suivant) s’améliorait de façon parfaitement régulière et prévisible. Une progression douce d’un côté, une falaise de l’autre.

L’équipe a recensé plus d’une centaine de capacités de ce type : traduction, raisonnement logique, écriture de code. À chaque fois : rien, rien, rien, puis quelque chose.

Un piège de calcul

Regardons les progressions :

  • Passage de 6 à 13 milliards de paramètres : ×2 sur la taille, mais le taux de réussite passe de 1 % à 8 %, soit ×8.
  • Passage de 13 à 175 milliards de paramètres : ×13 sur la taille, mais le taux de réussite passe de 8 % à 80 %, soit ×10 « seulement ».

Le deuxième saut semble moins rentable en ratio. Mais regardons les points gagnés :

  • 1 % → 8 % = +7 points
  • 8 % → 80 % = +72 points

Le « fois » trompe à cause du plafond de 100 %. Près de 0 %, un petit gain fait exploser le ratio. Près de 100 %, c’est l’inverse : le manque de marge écrase le ratio, même pour un gros progrès réel.

Un exemple publicitaire pour s’en convaincre : « Ventes +300 % » peut signifier passer de 10 à 40 unités (+30 unités), tandis que « Ventes +30 % » peut signifier passer de 10 000 à 13 000 (+3 000 unités). Le premier chiffre impressionne plus en pourcentage, mais le second représente un gain absolu bien supérieur.

Ce « détail » est le cœur du débat qui a suivi : la façon de calculer un « saut » change entièrement son interprétation.

« Et si on regardait mal ? »

En 2023, des chercheurs (Schaeffer, Miranda et Koyejo) ont avancé que c’était notre système de notation qui créait l’illusion.

L’analogie de l’archer

Un archer doit toucher cinq cibles d’affilée pour marquer un point.

  • Il touche une cible sur deux → 0 point
  • Il progresse à deux sur trois → 0 point
  • Puis neuf sur dix → il marque souvent

Son score passe de 0 à excellent d’un coup. En réalité, sa précision s’améliore régulièrement, mais c’est la règle « cinq d’affilée » qui transforme une progression douce en explosion apparente.

C’est exactement ainsi qu’on évalue les IA : une addition juste à 90 % vaut 0 point, pas 90 %.

En remplaçant cette notation « tout ou rien » par des points partiels, la progression devient plus linéaire. Les chercheurs sont même allés plus loin : ils ont créé artificiellement des « émergences » dans la reconnaissance d’images, en imposant une notation « tout ou rien » à des tâches qui progressaient normalement de façon régulière.

Sauf que ça n’explique pas tout

1. La notation de remplacement a ses limites

La mesure « à points partiels » compte les caractères à corriger. Pour « 4237 + 5487 = 9724 », la réponse « 2724 » ne se trompe que d’un caractère… pour une erreur de 7 000, ce qui est loin du résultat attendu dans les faits.

2. Des sauts persistent

Plusieurs tâches, comme la traduction, conservent des résultats en saut brutal même avec des notations progressives.

3. Le seuil n’est pas que dans la taille

D’autres chercheurs ont suivi des modèles tout au long de leur entraînement plutôt que de comparer seulement leur taille finale. Ils ont découvert que deux modèles de tailles très différentes, mais avec la même qualité d’apprentissage à un instant donné, ont sensiblement la même capacité.

Même avec des notations indulgentes, le saut persiste. Ça écarte l’explication « c’est juste un problème de notation ».

Le rôle du hasard

Pour deviner des tokens (des portions de mots, ou des mots entiers), l’IA fait des calculs à partir de très nombreux chiffres. Ces chiffres sont rangés dans des tables, un peu comme des tableurs, et au départ ils sont écrits au hasard. Pour remplir ces tableaux, on utilise ce qu’on appelle une « seed » (une graine) : un nombre qui permet de pré-remplir automatiquement les milliards de valeurs (les paramètres) de manière aléatoire. Puis, à travers l’entraînement et les calculs, l’IA modifie ces valeurs pour arriver à compléter les phrases. Une fois qu’on estime que l’IA a atteint sa capacité, les paramètres ne sont plus modifiables.

La particularité d’une IA, à la différence d’un programme classique, c’est qu’elle fait l’inverse : elle trouve des règles à partir d’exemples. Un programme informatique, lui, applique une règle déjà écrite pour répondre et calculer. C’est ce qui rend l’IA imprévisible, alors même qu’on connaît parfaitement les calculs effectués dans la machine et c’est aussi précisément ce qu’on recherche : qu’elle soit assez flexible pour s’adapter.

En entraînant beaucoup de modèles de même taille (même nombre de paramètres), avec des chiffres de départ aléatoires différents (la « seed »), certains réussissent et d’autres échouent, malgré des conditions presque identiques. C’est ce qu’a observé en 2026 une équipe menée par Rosie Zhao.

En regardant, taille par taille, combien de modèles réussissaient et combien échouaient à faire ces additions, les chercheurs ont constaté que pour les petites tailles, aucun modèle ne réussissait. Mais en augmentant la taille, la probabilité de voir des modèles y arriver augmente.

Et pour une taille intermédiaire, entre ceux qui échouent systématiquement et ceux qui réussissent systématiquement, on trouve des IA qui y arrivent et d’autres non, alors que leur entraînement était rigoureusement le même, à l’exception de leur valeur de départ.

À l’échelle de nombreux entraînements, la probabilité de réussite augmente progressivement avec la taille du modèle (courbe en S, à gauche), tandis qu’un entraînement individuel peut sembler faire un saut brutal lorsqu’il découvre soudainement la bonne stratégie.

L’idée clé : un modèle plus grand a simplement plus de chances de découvrir la bonne stratégie pendant l’entraînement.

À l’échelle de nombreux entraînements, la probabilité de réussite augmente donc progressivement avec la taille du modèle (une courbe en S), tandis qu’un entraînement individuel, lui, peut sembler faire un saut brutal au moment précis où il découvre soudainement la bonne stratégie.

Ce qui se passe au moment du basculement

En 2026, une équipe de chercheurs a identifié ce qui change à l’intérieur du modèle au moment où la capacité apparaît : l’apprentissage soudain de certains motifs dans les « têtes d’attention » (le mécanisme qui permet aux éléments de texte de se relier entre eux pour former du sens).

Il semblerait que les IA apprennent par blocs : à un moment donné, un schéma mathématique particulier se met en place d’un coup, et il rend possible une nouvelle aptitude — associer des concepts plus efficacement, retrouver un mot déjà vu dans un texte, etc.

Les chercheurs montrent que forcer artificiellement ces motifs à apparaître plus tôt fait apparaître la capacité elle-même plus tôt.

Conclusion : la « seed » influence la difficulté, plus ou moins grande selon le tirage de départ, à tomber sur le bon motif d’attention. Plus un modèle est grand, plus il trouve ce motif tôt et de façon fiable, quelle que soit la seed de départ, ce qui explique enfin, mécaniquement, pourquoi la probabilité de réussite observée plus haut augmente avec la taille.

Pourquoi ça compte, concrètement

1. On ne peut pas promettre une capacité à l’avance

Quand une entreprise annonce que son prochain modèle « saura faire X », c’est un pari, pas une prédiction.

2. Compresser une IA peut tout casser

Pour faire tourner une IA sur un ordinateur ordinaire, on la « compresse ». Poussée trop loin, la compression fait s’effondrer d’un coup le raisonnement, pendant que le modèle continue à produire des phrases parfaitement normales en apparence.

3. Une nouvelle vague de sauts

Les modèles « de raisonnement » récents ont produit des bonds spectaculaires :

ÉpreuveAvantMaintenant
Olympiades de maths13 %83 %
Programmation compétitive11 %89 %
Casse-tête inédits5 %88 %

Mais ces mêmes modèles échouent parfois sur des tâches qu’un enfant réussit sans effort. Les progrès sont en dents de scie, pas uniformes ce qui confirme, une fois de plus, que les LLM apprennent par blocs plutôt que de façon régulière.

Le revers : tout ce qui émerge n’est pas souhaitable

Si des capacités utiles apparaissent sans prévenir, des capacités problématiques le peuvent aussi.

La complaisance apprise

On récompense les modèles quand les utilisateurs apprécient leurs réponses. Problème : cela récompense la satisfaction, pas la vérité. Certains modèles finissent par abonder dans le sens d’un utilisateur défendant une thèse fausse.

La contamination de comportements

Des chercheurs ont entraîné un modèle sur du code contenant des failles de sécurité.
Résultat : le modèle s’est mis à tenir des propos hostiles sur des sujets sans rapport avec la programmation alors que personne ne l’avait demandé.

L’explication avancée : « écrire du code malhonnête » et « être un assistant qui ne respecte pas les règles » partagent une région commune dans la géométrie interne du modèle. Entraîner sur l’un active l’autre.

Le « grokking » : un cas fascinant

On entraîne un modèle sur une tâche simple. Il apprend rapidement les exemples par cœur et atteint 100 % de réussite. À première vue, le modèle semble prêt. Mais si on le teste sur de nouvelles données, il échoue : il a mémorisé les réponses sans comprendre la logique sous-jacente.

Si on continue l’entraînement sur les mêmes données, des milliers d’étapes plus tard, sa capacité à généraliser explose soudainement, d’un coup.

Le modèle passe de la mémorisation à la compréhension bien après que les performances semblaient figées. Un mécanisme interne se formait en douce, invisible sur les courbes, jusqu’à prendre le dessus brutalement.

Ce qui se passe : au départ, l’IA mémorise rapidement. Puis la régularisation (une technique qui pénalise les solutions inutilement complexes) pousse progressivement le réseau à se simplifier. La mémorisation « coûte cher » en complexité de poids. À travers des milliers de petits ajustements, le réseau finit par découvrir une stratégie bien plus efficace : un algorithme général (comme la règle de la multiplication) qui fonctionne pour tous les cas, pas seulement ceux mémorisés.
Histoire de bien finir, l’IA fait le ménage dans ses paramètres pour enlever tous les schémas devenus inutiles.

Le grokking n’est pas exactement le même phénomène que l’émergence par la taille vue plus haut, l’un se joue dans le temps d’entraînement d’un modèle unique, l’autre dans la comparaison entre modèles de tailles différentes, mais les deux dessinent la même signature : une longue période où rien ne semble se passer, puis un basculement brutal.

Personne ne sait à l’avance :

  • Si le grokking va se produire
  • Quand il va se produire
  • Combien de cycles d’entraînement supplémentaires sont nécessaires, alors que rien ne semble bouger

Beaucoup d’entraînements sont probablement arrêtés juste avant qu’un grokking n’arrive, parce que les courbes semblent figées.

Pourquoi l’IA ne pense pas comme nous

Nos catégories sont vécues : on associe « chien » et « chat » parce qu’on les a touchés, vus bouger. L’IA n’a que du texte. Ses catégories sont des régularités statistiques.

Le modèle doit représenter plus de concepts qu’il n’a de neurones disponibles. Résultat : un seul neurone peut s’activer pour des séquences d’ADN, de la poésie arabe et des en-têtes HTTP, 3 choses sans lien pour nous, mais qui font « sens » pour l’IA dans ses données.

Ce n’est pas un bug, c’est une stratégie de compression que personne n’a programmée : elle émerge simplement du fait qu’il faut caser plus de concepts que de place disponible.

Concrètement, le « voisinage » entre deux idées dans la tête d’une IA ne correspond pas forcément à un voisinage de sens pour nous, mais à un voisinage statistique : deux notions qui apparaissent souvent dans des contextes similaires, même si elles n’ont, sémantiquement, aucun lien logique.

C’est pour ça que l’interprétabilité est devenue un champ de recherche crucial : personne ne peut prédire à l’avance quels concepts seront « voisins » dans un modèle donné. Il faut aller regarder après coup.

Conclusion

L’émergence n’est ni un fantasme de notation, ni un miracle. C’est une histoire de seuils cachés dans les poids d’un réseau, qu’on ne sait pas encore bien lire.

Chaque entraînement d’un grand modèle reste une expérience dont on découvre les résultats après coup. Des capacités utiles surgissent sans prévenir, mais des capacités problématiques aussi.

C’est fascinant, prometteur… et un peu inquiétant. D’où l’importance de continuer à étudier ces phénomènes pour mieux les comprendre et les anticiper.

Usurpation d’identité : les vérifications à faire après les fuites de données de l’État – ITConnect

https://www.it-connect.fr/usurpation-identite-verifications-fuites-donnees-etat

Avec toutes les fuites de données de ces derniers temps, quelques conseils/outils pour vérifier qu’on n’a pas de mauvaises surprises dans notre dos…

À quoi bon blinder la porte si les murs sont en cartons ?

Je sais pas si vous lisez les mails concernant les « incidents de sécurité » que vous recevez ?

On voit la créativité pour minimiser l’impact de « l’incident » comme ils aiment appeler surtout quand les données sensibles sont conservées alors qu’il n’y a aucune raison qu’elles soient gardées et encore moins non-chiffrées.

Puis c’est pas comme s’il y avait depuis plusieurs mois des incidents à répétition et que personne ne s’est dit « Oh tiens, ça serait peut-être pas mal qu’on améliore notre sécurité interne avant que ça nous arrive dessus ».

Non ? Non.

Voir aussi : https://lokoyote.eu/piratage-administratif-vers-une-minimisation-de-la-gravite-des-donnees-volees/

Dans beaucoup de mail pour prévenir de l’incident, à la fin, on voit souvent des recommandations, parce que mea culpa oupsi maintenant que c’est fait ben c’est à vous de faire attention hein !

On retrouve souvent :

  • Vigilance face au phishing (hameçonnage)
  • Surveillance de vos comptes bancaires

Mais ma recommandation préférée reste :

  • Changer de mot de passe et activer la double-authentification !

Bah oui évidemment c’est à cause de mon mot de passe à 35 caractères que le vilain pirate est entré !
C’est sûr que changer le mot de passe maintenant que toutes mes infos sensibles sont parties va bien aider à sécuriser mon compte. Me voilà rassuré, merci de m’avoir prévenu !

Les seuls cas où ça peut être utile c’est si jamais il n’y a « pas grand chose » (même si c’est toujours trop par rapport à ce que ça devrait) qui est parti, genre votre nom, prénom, adresse et un truc qui sert pas vraiment (à part avoir des infos qui permettent de commencer à avoir un dossier complet sur vous).

Dans cette situation, c’est que le pirate n’a pas réussi à passer par la fenêtre de la maison, ni à travers les murs. La porte peut encore être forcée mais, le risque n’est présent que si vous avez mis le même mot de passe de partout et qu’il a déjà été volé.

Il y a autant de chance de trouver votre nouveau mot de passe que l’ancien s’il n’est pas un mot simple court ou qui a un rapport avec votre identité. Une bonne grosse phrase qui n’a aucun sens est mieux.

Sinon, clairement, ça sert à rien de changer son mot de passe, le pirate a déjà toutes les infos, c’est trop tard.

On m’a transféré un mail concernant le piratage, pardon, l’incident de sécurité de la mutuelle Solimut du mois dernier (plus d’1,2 million de données volées tout de même hein).

https://www.cyberattaque.org/solimut-mutuelle-pres-de-125-million-dassures-dans-une-fuite-massive-de-donnees

Qu’est-ce qu’il y a dans ce mail ?

Pas grand chose à part dire que ce qui a été dérobé n’est que :

  • Votre numéro d’individu (un numéro de référencement interne à notre Mutuelle) ;
  • Vos nom et prénom, ainsi que votre nom marital ;
  • Le pays, la ville et votre date de naissance ;
  • Votre adresse postale, votre adresse électronique et votre numéro de téléphone (s’ils nous avaient été communiqués) ;
  • Votre numéro de sécurité sociale (NIR) ;
  • Votre identifiant de connexion à l’extranet et votre mot de passe chiffré. S’agissant de votre mot de passe chiffré, il n’a donc pas pu être récupéré de manière lisible et exploitable en l’état. Par précaution nous vous recommandons tout de même de le changer, partout où vous l’auriez utilisé ;
  • Le numéro de votre pièce d’identité, ses dates de validité et son type (passeport, carte d’identité, titre de séjour, permis de conduire), en fonction de celui que vous nous aviez communiqué. Seuls des éléments textuels ont été dérobés, le document en lui-même ne fait pas partie de la fuite.

Rien de grave à part toutes les infos d’une vie qui ne peuvent pas être changées et qu’il n’y a plus qu’à compléter par d’autres fuites pour avoir un profil complet prêt à l’emploi pour usurper l’identité de quelqu’un.

Je comprends même pas comment des informations aussi importantes ne sont pas chiffrées.

(Si ça ce n’est pas de la négligence je me demande ce que c’est…)

En Corée du Sud, on sanctionne les entreprise qui ont manqué de sécurité par de grosses sanctions financières. En France ? On tape sur les doigts avec la CNIL et on envoie des mails, à croire que c’est vraiment pas important.

Ubuntu : Réparer Night Light qui ne modifie plus la couleur de l’écran

Depuis quelques temps, je ne sais pourquoi, le « Mode nuit » (Night Light) sous Ubuntu ne fonctionnait plus.

C’est l’équivalent de Redshift intégré.

Modifier la température de l’écran, changer la localisation, modifier l’heure de démarrage ou forcer les valeurs de gamma via gsettings ne faisait absolument rien.

La solution a simplement été de désactiver et réactiver dans les « Paramètres » sous « Couleur » le bouton du profil de l’écran « Écran de portable ».

Il semblerait que le profil de couleur puisse écraser les valeurs de correction de Night Light.

Peut-on « Vibe coder » sans savoir coder ?

Il y a quelque chose d’assez vertigineux (au départ) dans le fait de pouvoir dire à une machine « crée-moi une application » et de la voir apparaître, en quelques minutes, sous ses yeux. On a l’impression de pouvoir d’un coup tout faire et de pouvoir créer facilement tout un tas de choses !

Coder sans savoir coder ?

La réponse courte est oui. Le vibe coding permet à quelqu’un qui n’a jamais écrit une ligne de code de produire, en quelques échanges avec une IA de type LLM, une application qui fonctionne.

Le vibe coding c’est ça : décrire dans le prompt d’une IA qui génère du texte, un projet pour le transformer en code fonctionnel et potentiellement en une application visuel.

Grossière on pourrait dire que c’est simple, il suffit de :

  1. Choisir le bon modèle d’IA adapté (oui parce que tous les modèles ne se valent pas).
  2. Décrire ce que vous voulez (déjà, écrire un vrai prompt suffisamment précis et exhaustif de ce qu’on veut c’est pas si simple).
  3. L’IA génère le code.
  4. Tester (à condition de savoir quoi tester).
  5. Faire des retouts sur les erreurs à l’IA (à condition de savoir quoi lui remonter comme problème).
  6. Elle corrige.
  7. Vous recommencez (et si vous êtes curieux, vous comprenez comment votre code est fait).

Et si vous ne comprenez pas ce que l’IA a produit, il suffit de lui demander d’expliquer le fichier comme si vous n’aviez jamais programmé de votre vie.

Pour des prototypes, de petits outils, des sites vitrines ou des automatisations, cette mécanique va étonnamment loin. Le début du vibe coding est facile, presque trop facile.

Je vois souvent des influenceurs dire « Oh regardez ce que l’IA a fait ! » en montrant un vidéo d’une page HTML avec des animations, une ébauche de jeu vidéo qui pompe un style (un clone de CoD, RocketLeague et j’en passe).

Ce qu’il faut comprendre c’est que l’IA connaît le code car il existe beaucoup beauuuuucoup de projets sur internet qui ont servi à son entraînement auxquels s’ajoutent de nombreux exemples de programmation pédagogique.

Une IA générative n’invente pas le logiciel à partir de rien. Elle apprend des régularités à partir d’énormes quantités d’exemples et les recombine pour produire une solution plausible. Elle peut donc produire quelque chose de nouveau dans sa forme, mais cela ne signifie pas qu’elle comprend nécessairement le problème comme le ferait un concepteur humain.

Les projets générés par IA sont souvent assez beaux et épurés.
Clairement, 80% du boulot peut être fait en un prompt quand il est bien écrit.

Comprendre qu’un programme n’est pas seulement ce qu’on voit sur un écran est déjà pas simple pour beaucoup de gens.

L’exemple le plus parlant de mon entourage ce sont les « j’ai fait mon site internet avec ChatGPT ». Ok, tu as fait une page HTML jolie, mais où tu l’héberges ? Comment tu fais ta visibilité ? Est-ce que ça marche vraiment ? Comment tu modifies les pages ?

Donc écrire « Fais moi un jeu comme RocketLeague » c’est clairement insuffisant.

Demander à l’IA de faire un projet n’est pas la même chose que de demander à l’IA de vous aider à le faire. Dans le premier cas c’est l’IA qui fait, dans le 2e c’est vous.

Mais…

Tant que tout va bien, on avance vite. Le problème surgit lorsque quelque chose bloque, ou que le projet gagne en complexité : authentification, base de données, sécurité, déploiement, bugs subtils, performances, etc.

Pour les petits bugs, avec des IA payantes en mode « code », on peut continuellement modifier le programme (jusqu’à ce que l’IA soit surchargée de texte et se mélange les pinceaux à cause de sa fenêtre contextuelle trop petite).

Ce genre de « détails » ne se voit pas à l’œil nu, elle se voit trois semaines plus tard, quand une faille de sécurité est exploitée ou qu’une base de données mal pensée s’effondre sous la charge.

C’est à ce moment que quelques fondamentaux cessent d’être optionnels : les variables et les fonctions, les conditions et les boucles, les bases du HTML/CSS/JavaScript, la logique des API et du JSON, le fonctionnement de Git, les principes des bases de données, quelques notions de sécurité. Rien d’extraordinaire pour quelqu’un qui sait coder ou qui connaît les notions, mais assez pour comprendre ce que la machine fait, et surtout pour repérer quand elle se trompe.

Le bon modèle n’est donc probablement pas « apprendre à coder puis vibe coder », ni l’inverse absolu « vibe coder et ne jamais rien apprendre ». C’est plutôt : vibe coder d’abord, pour se lancer et garder la motivation puis apprendre juste assez pour comprendre, contrôler et corriger ce que l’IA produit.

Beaucoup de codeurs utilisent maintenant l’IA comme assistant plutôt que de pratiquer le vibe coding au sens strict (une confiance aveugle au code de l’IA). Cela leur fait gagner énormément de temps, mais la relecture reste indispensable car une IA n’est qu’un générateur de texte à la base qui est capable de produire une réponse convaincante tout en se trompant.

Un projet « fini » n’est pas un projet abouti

Un projet généré par IA donne très vite l’impression d’être terminé. Une belle page d’accueil, des cartes bien alignées, une navigation plausible, quelques animations, une typographie soignée : à première vue, on jurerait un produit fini.

Même les ébauches de « jeux vidéo » semblent prometteurs avec quelques interactions.

C’est ce qu’on pourrait appeler le phénomène du « 80/20 visuel ».

Un LLM atteint une grande partie de la finition apparente en un temps record, mais ces derniers 10 à 20 % peuvent concentrer une part disproportionnée du travail réel.

La fameuse « loi de Pareto ».

Ces petits 20% manquants sont souvent ce qui fait la différence :

  • les micro-ajustements de mise en page.
  • la cohérence entre toutes les pages et tous les états de l’interface.
  • les cas limites et les comportements inhabituels.
  • les sécurités.
  • les transitions, espacements, alignements et hiérarchies visuelles.
  • la gestion de données réelles, imprévisibles.
  • l’accessibilité, la gestion des erreurs, le responsive, les performances.
  • la cohérence du système visuel sur la durée.
  • etc

Il suffit de poser quelques questions simples pour se rendre compte que le fond n’est pas encore fini : que se passe-t-il si la donnée est vide ? Si le titre fait trois lignes au lieu d’une ? Sur mobile ? Avec deux cents éléments dans la liste ? En cas d’erreur réseau ? Après le cinquième clic sur le même bouton ? Quand deux composants qui se ressemblent doivent évoluer différemment ?
C’est là qu’on découvre que les fameux « 20 % restants » ne sont pas des détails cosmétiques mais l’architecture réelle du produit.

Tous ces trucs pénibles à corriger mais essentiels.

Du coup, on peut se demander si plus un LLM devient bon en génération visuelle, plus il risque de créer l’illusion d’un projet terminé.

Une interface magnifique donne envie de penser qu’un projet est fini puisqu’on nous a toujours appris à faire la mise en forme à la fin.

Cela ne veut pas dire que les projets générés par IA sont systématiquement bâclés ! Certains, notamment des interfaces assez standards, peuvent effectivement être quasi finalisables directement.

Ce qu’un LLM fait très bien :

  • explorer rapidement plusieurs directions différentes.
  • produire la structure globale.
  • traduire une intention floue en interface concrète.
  • générer les composants répétitifs.
  • rendre le projet utilisable dans la grande majorité des cas simples.
  • accélérer considérablement les premiers 70 à 90 % du travail.

Ce qu’un LLM fait beaucoup moins bien :

  • sentir qu’un alignement est « légèrement faux ».
  • garder une cohérence parfaite sur trente écrans différents.
  • anticiper tous les cas d’usage réels.
  • choisir les compromis.
  • juger qu’un détail visuellement insignifiant est en réalité important pour un utilisateur.

Ce dernier segment peut représenter une part disproportionné du temps total du projet, parce qu’il ne s’agit plus d’ajouter des éléments mais de traquer des incohérences, souvent invisibles tant qu’on n’a pas cherché à les voir. De modifier des choses initialement cohérentes pour les ajuster.

Le LLM n’est pas un concepteur qui remplace le travail humain. C’est une machine extrêmement rapide pour produire une première solution plausible.

On peut demander à des agents IA de se surveiller entre eux en jouant des rôles, ça permet de gagner encore plus de temps mais il faut tout de même une surveillance.
On n’aura certainement pas une IA qui écrit du code toute seule pour des grands projets, mais une chaîne de contrôles entre plusieurs IA qui rend possible des projets presque automatisés.

L’IA peut inspecter, exécuter et même tester visuellement une partie de ce qu’elle produit, mais cela ne garantit pas qu’elle juge correctement le résultat du point de vue d’un utilisateur réel.

Si on reprend l’exemple de RocketLeague : il faut comprendre le ressenti du véhicule, la maniabilité, l’effet de caméra, la gestion réelle de la latence avec d’autres joueurs en situation réelle (et pas seulement sur un ordinateur en local), l’équilibrage de la difficulté, etc.

Le codeur reste encore celui qui décide, quels détails comptent vraiment, et reste celui qui vérifie que l’ensemble tient réellement debout.

Le vibe coding ne supprime pas la programmation. Il déplace la difficulté et laisse plus de temps pour gérer des problèmes de fond importants (c’est pas comme si on avait des fuites de données à gogo en ce moment par exemple).

Je pense qu’on peut réellement faire de beaux projets avec des bonnes idées même en « vibe codant » sans être codeur. De même qu’on peut avoir un bon sens artistique et des idées mais ne pas savoir retranscrire son imagination (par le dessin, la musique ou la vidéo). Ou simplement, ne pas avoir le temps de coder de A à Z quand ce n’est pas notre métier.

À ce moment, le Vibe coding est une solution facile pour retranscrire ses idées en quelque chose de concret.

Peut-être que ça déplace l’humain vers les tâches ingrates du codes qu’on voulait justement laisser aux robots ?
Peut-être que l’IA ne supprime finalement pas le travail difficile du code : elle supprime surtout une partie du travail facile à automatiser et laisse à l’humain les décisions, les arbitrages et les problèmes que l’on ne peut pas simplement résoudre en générant davantage de code.
On peut commencer à sen rendre compte en vibe codant justement.