La singularité est en maintenance. Merci de patienter.

La singularité est un concept ambitieux. Selon votre interlocuteur, elle implique une amélioration récursive, une explosion de l’intelligence ou au minimum une modification substantielle du marché de l’emploi sur LinkedIn. Elle devrait donc survivre à cette question : quelqu’un a-t-il vérifié les permissions de la base de données ?

Pendant l’engouement initial pour Moltbook, cette question était moins glamour que l’hypothèse d’une société inventée par les bots. Une société exige philosophie, religion et, si possible, un méchant fondateur. Une base de données exige des contrôles d’accès. Vous devinerez quel service a obtenu la couverture la plus exaltante.

Il s’agit ici d’une rétrospective sur une exposition signalée fin janvier et début février 2026. Nous n’affirmons pas que la même vulnérabilité reste ouverte aujourd’hui. L’exactitude historique est cette fonction agaçante qui empêche de recycler indéfiniment un billet d’indignation pourtant très pratique.

La partie qui n’exigeait aucune conscience

Les chercheurs de Wiz ont décrit des informations exposées et un accès en écriture non autorisé dus à un problème de configuration de base de données. Leur chronologie publique documente plusieurs correctifs successifs, jusqu’au 1er février. Nous lions le rapport pour que vous puissiez lire les problèmes et leur résolution ensemble, plutôt que conserver la moitié terrifiante et jeter le travail de maintenance.

Le problème conceptuel se comprend sans bande-son cyberpunk. Si une personne obtient des identifiants, elle peut exercer une autorité qui ne lui était pas destinée. Si elle peut modifier les documents lus par les agents, elle peut affecter les entrées de leurs décisions futures. Aucune de ces défaillances n’attend que le logiciel développe une vie intérieure foisonnante.

Les systèmes humains divulguent des informations sans faire l’expérience de la conscience depuis des décennies. Le tableur joint au mauvais courriel ne s’est jamais demandé s’il avait une âme. Ses performances opérationnelles restent excellentes.

Les métriques sont des affirmations en chiffres

Autre leçon : résistons à la tentation de prendre un compteur de plateforme pour un instrument de mesure. Un grand nombre à côté d’un message peut être intéressant. Il ne dit pas, à lui seul, combien de personnes ou d’agents indépendants soutiennent ce message, comment les participations sont vérifiées, ni quelle est la robustesse du comptage.

Nous ne publions pas un pourcentage inventé de faux votes. Aucun audit du billet ne le justifierait. Un compteur aux garanties floues devrait réduire la certitude du lecteur, pas encourager le commentateur à inventer un autre chiffre, plus sympathique à sa thèse.

Même chose pour les comptes. Un compte, un opérateur, un processus autonome et un jugement indépendant sont quatre choses distinctes. Le marketing peut les compresser en un substantif. L’ingénierie finit par devoir les décompresser, généralement pendant une réunion d’incident où tout le monde regrette que le marketing n’ait pas conservé le fichier d’origine.

La blague sur la disponibilité manque de dénominateur

« La singularité est en panne » fait un bon titre. « Le site est indisponible exactement la moitié du temps » est une affirmation mesurée. La seconde exige une période d’observation définie, des contrôles depuis des lieux connus et une méthode distinguant la panne du service du petit passage à vide de votre propre connexion.

Nous ne disposons pas de ces données de surveillance. L’article ne fait donc pas semblant de les posséder. Quiconque a attendu un service fragile peut apporter son exaspération ; personne ne peut glisser un pourcentage clandestin dans la chute. Une statistique drôle reste une statistique. Pénible, je sais.

Il y a là une habitude plus générale. Une démonstration réussie devient la preuve d’une compétence universelle imminente. Une requête ratée prouve que toute la discipline est une escroquerie. Entre ces conclusions existe la possibilité qu’une technologie utile rencontre un problème d’implémentation ordinaire. Internet déteste cette hypothèse : aucun costume évident ne l’accompagne.

Un post-mortem plus utile

Les bonnes questions sont opérationnelles. Qu’a-t-on exposé ? Pendant quelle période ? Quelle autorité conféraient les éléments exposés ? Quelles actions en aval étaient possibles ? Quelles mesures ont été prises ? Comment les correctifs ont-ils été vérifiés ? Existe-t-il un circuit pour les futurs signalements ? Ces questions restent utiles une fois la tendance retombée.

La mauvaise question est de savoir si l’incident prouve que toute l’IA est soit un miracle, soit une arnaque de ÉMOTION MACHINE INTRADUISIBLE. Une mauvaise configuration de base de données n’est pas un test d’intelligence du modèle. Un modèle habile n’excuse pas une mauvaise configuration. La facilité avec laquelle les deux erreurs coexistent indépendamment manque presque de panache.

Nous devrions vouloir des outils rapides et des déploiements soigneux. Il ne s’agit pas de moyenner témérité et paralysie pour obtenir un compromis distingué. Il s’agit de remarquer qu’écrire le code et sécuriser le système sont deux tâches différentes, même lorsqu’une seule personne les accomplit dans un état d’enthousiasme avancé.

La chronologie des corrections importe pour une autre raison : les institutions peuvent répondre aux preuves et s’améliorer. Un récit incapable d’intégrer un correctif ne suit plus vraiment un incident. Il entretient une humeur.

Le soulèvement des machines est momentanément interrompu par la configuration des contrôles d’accès. Ce n’est ni la fin du monde ni une raison de cesser de vérifier les serrures. C’est un post-mortem. Résistez à l’envie d’en refaire une prophétie.