Un bug d'horaire sur Arthur m'a coûté une heure cet été — pas à cause de l'IA, mais parce que j'avais arrêté de tenir mes propres notes à jour. Trois expériences personnelles et plusieurs études récentes pointent vers la même chose : ce qu'on choisit de continuer à comprendre soi-même, face à l'IA, compte plus que l'outil lui-même.
Le bug UTC sur Arthur
Été 2026. Sur Arthur, mon assistant personnel, une heure était mal affichée : stockée au format UTC — le fuseau horaire de référence utilisé par la plupart des systèmes informatiques —, elle était relue comme si c'était l'heure locale, avec plusieurs heures de décalage à la clé. Un bug ordinaire, en soi.
Ce qui a fait durer la correction n'est pas venu de là. Pendant cette période, j'avais arrêté de tenir à jour mes propres fichiers de suivi de projet — les notes qui disent à l'IA où en est le développement, quelles décisions ont été prises, ce qui reste à faire. Le contexte que je transmettais à l'IA était devenu incohérent avec l'état réel du code. L'IA, recevant des informations qui se contredisaient, a fini par douter de ce que je lui disais, et la correction a tourné en boucle : plusieurs échanges, environ une heure perdue.
Ce n'est pas l'IA qui s'est trompée. C'est moi qui avais relâché ma discipline de suivi sur un point qui ne m'intéressait pas ce jour-là — et l'IA n'avait aucun moyen de m'aider correctement avec des informations que je lui donnais moi-même de travers.
Ce que ça révèle
Ce moment pointe vers une question plus large que « faut-il utiliser l'IA ». La vraie question, c'est : qu'est-ce qu'on choisit de continuer à comprendre soi-même, plutôt que de déléguer entièrement ?
Ce n'est pas propre à mon cas. Une étude menée par Microsoft et l'université Carnegie Mellon, relayée en mai 2026, auprès de 319 travailleurs du savoir et sur 936 exemples d'usage réels de l'IA, montre qu'une confiance plus grande dans l'IA est associée à un effort cognitif moindre pour évaluer ce qu'elle produit : seuls 36% des participants ont déclaré appliquer un jugement critique sur les réponses reçues.
En France, un état des lieux publié par Cyberini en 2026 va dans le même sens : l'usage de l'IA progresse plus vite que sa maîtrise. La moitié des Français déclarent l'utiliser, mais une minorité seulement sait vraiment s'en servir, et les trois quarts des actifs n'ont reçu aucune formation sur le sujet.
Le risque à plus grande échelle
Ce relâchement, à plus grande échelle, a un nom : le « vibe coding » — une pratique qui consiste à faire écrire l'essentiel du code par une IA, en formulant ce qu'on veut en langage courant, sans chercher à comprendre ni à vérifier ce qui est produit. Le risque n'est pas théorique.
Une note de recherche de la Cloud Security Alliance, publiée en mai 2026 et citant une étude Veracode, mesure que 45% des échantillons de code généré par IA introduisent des vulnérabilités reconnues du classement OWASP Top 10 — la référence des risques de sécurité les plus courants pour une application web. Ce taux reste stable depuis 2025, malgré les annonces des fournisseurs de modèles sur l'amélioration de leurs outils.
Un cas concret l'illustre : en janvier 2026, des chercheurs en sécurité de Wiz ont découvert que la base de données de production d'un réseau social propulsé par IA — Moltbook — était exposée publiquement depuis trois jours, avec 1,5 million de jetons d'authentification et 35 000 adresses email accessibles. Le fondateur du projet avait déclaré n'avoir écrit aucune ligne de code lui-même. La cause : un déploiement mal configuré, jamais vérifié par une personne qui en comprenait les implications.
Le contre-exemple qui marche
L'inverse existe aussi, et j'en ai fait l'expérience directement. En avril 2026, Client Tracker Lite — mon premier agent connecté à une vraie base de données, sans les outils de suivi que j'utilise aujourd'hui — produisait des résultats souvent faux. Je ne me suis pas contenté de redemander à l'IA de corriger : je suis allé chercher moi-même, par mes propres recherches, pourquoi ces erreurs se produisaient.
Cette compréhension acquise à la dure a servi plus tard, sur Arthur — un projet plus abouti que Client Tracker Lite. Plutôt que de la garder pour moi de façon informelle, j'ai utilisé l'IA pour la mettre en forme : un document de onze pages qui nomme les schémas d'erreur récurrents, définit un vocabulaire précis pour en parler, et hiérarchise leurs causes. L'IA n'a rien inventé dans ce document — elle a structuré une compréhension que j'avais déjà acquise par l'expérience. C'est une différence qui compte : utiliser l'IA pour organiser ce qu'on sait déjà n'est pas la même chose que lui demander de savoir à notre place.
La limite qui reste
Reste une limite que ni la discipline ni la vigilance ne suppriment complètement : elles la rattrapent, elles ne l'empêchent pas. Sur Rooted, un site e-commerce que j'ai développé à titre d'exercice, la configuration proposée pour connecter la base de données n'était plus la bonne — un réglage qui a changé de méthode d'une version à l'autre de l'outil utilisé, et que le modèle a suggéré à l'ancienne manière, périmée.
Je l'ai repéré parce que je savais à quoi ressemblait la configuration attendue. Sans cette connaissance préalable, rien dans la réponse de l'IA n'aurait signalé le problème : elle est formulée avec la même assurance, qu'elle soit à jour ou non. C'est la limite qui reste, quoi qu'on fasse : l'IA peut proposer une information périmée en toute confiance, et seule une compréhension déjà là permet de s'en apercevoir.
Ce qui reste à surveiller
Le bug UTC, le vibe coding, Client Tracker Lite, Rooted : quatre situations différentes, une seule ligne de force. L'IA comme outil d'émancipation suppose de continuer à comprendre ce qu'on lui délègue — sinon elle rend dépendant plutôt que compétent.
Ce n'est pas l'IA qu'il faut surveiller, c'est sa propre rigueur : elle ne comble les trous que si on les lui laisse.