Personne ne sait ce qu’il fait. Pas au sens banal et un peu auto-absolutoire des conversations entre collègues, quand quelqu’un hausse les épaules et dit qu’on improvise tous. En un sens plus précis, plus inquiétant, et surtout plus structurel : la complexité des objets techniques que nous avons construits a dépassé la capacité de tout humain isolé à les comprendre. Pas un défaut d’intelligence ou de formation. Pour une raison qui tient à la nature même de ces objets.
Pendant la majorité de l’histoire de la technique, il était possible de trouver au moins une personne qui comprenait un artefact dans son ensemble. L’aqueduc romain, le métier mécanique, la locomotive à vapeur, même un avion de la Seconde Guerre mondiale : systèmes compliqués, certes, mais en fin de compte ramenables à un savoir unitaire. Un ingénieur suffisamment formé pouvait tracer la chaîne causale d’un bout à l’autre. Il pouvait dire : je sais comment ça marche, pourquoi ça marche, ce qui se passe si ça casse. Cette possibilité n’était pas un détail. C’était le fondement de l’idée même de compétence technique — et avec elle, de responsabilité.
Ce fondement n’est plus là.
Le seuil
Le point de rupture ne fut pas soudain. Il s’est accumulé sur des décennies, invisible comme tous les changements par stratification plutôt que fracture. Chaque niveau d’abstraction ajouté au-dessus du précédent résolvait un problème et en créait un autre : rendre opaque le niveau inférieur. Le développeur applicatif d’aujourd’hui ne connaît pas vraiment le framework qu’il utilise. Qui connaît le framework ne connaît pas le runtime. Qui connaît le runtime ne connaît pas l’OS, pas vraiment. Qui connaît l’OS ne connaît pas le microcode du processeur. Et personne, vraiment personne, ne connaît la chaîne entière de dépendances qu’une seule commande d’installation télécharge depuis le réseau et intègre à son logiciel.
Pas une exagération polémique. Une description factuelle. Un projet logiciel moyen, en 2026, comprend des centaines de dépendances directes et des milliers de dépendances transitives. Chacune écrite par quelqu’un d’autre, avec ses propres dépendances, ses propres vulnérabilités, ses propres décisions d’archi prises dans un contexte que personne en aval ne reconstruira jamais. Exécuter du logiciel aujourd’hui, c’est faire confiance. Pas au sens noble de la confiance entre personnes, mais au sens épistémologique de qui renonce à vérifier parce que la vérification est matériellement impossible.
Il y a eu une époque où le mot « ingénieur » impliquait la possibilité d’un contrôle total sur son objet de travail. Cette époque est finie. Elle ne reviendra pas.
Le savoir comme illusion d’échelle
Le problème n’est pas qu’on en sait peu. C’est que le type de savoir qu’on possède n’est pas commensurable à la complexité de ce qu’on opère. On sait des choses. On en sait même beaucoup. Mais le savoir nécessaire pour comprendre un système distribué moderne n’est pas la somme des savoirs individuels : c’est un savoir qui demanderait un esprit capable de tenir simultanément des couches conçues pour être séparées.
L’abstraction, mécanisme fondamental de la pensée computationnelle, fonctionne précisément parce qu’elle cache. C’est son mérite et son piège. Une interface bien conçue te libère du besoin de savoir ce qui se passe dessous. Mais quand quelque chose tourne mal, tu découvres que « dessous » il y a un monde que personne dans la pièce ne connaît, et que personne au monde ne connaît peut-être dans son ensemble. Pas parce que le savoir n’existe pas, mais parce qu’il est distribué de manière irrécupérable entre des milliers de personnes qui ne se sont jamais parlé.
Une condition épistémologique nouvelle. Sans précédent dans l’histoire de la technique, et avec peu d’analogues dans l’histoire de la pensée. Le plus proche serait peut-être le problème de la division du travail chez Adam Smith, mais avec une différence essentielle : Smith parlait d’un processus productif où chaque ouvrier comprenait son morceau. Ici, personne ne comprend vraiment même son propre morceau, parce qu’il repose sur d’autres morceaux qui échappent par définition.
La chaîne brisée de la responsabilité
Si personne ne comprend le système dans son ensemble, la question de qui est responsable n’a pas de réponse satisfaisante. Pas faute de candidats, mais parce que le concept même de responsabilité présuppose ce qui manque ici : la possibilité de savoir.
Responsabilité, à la racine, signifie capacité à répondre. À rendre compte de ses choix. Mais comment rendre compte d’un choix fait dans un contexte qu’on ne pouvait comprendre entièrement ? Comment répondre d’un système dont le comportement émerge d’interactions entre composants qu’aucun acteur n’a conçus ni prévus ?
Le droit, qui a réfléchi à cela bien plus que l’informatique, a développé l’idée de diligence : pas besoin de tout comprendre, il suffit d’agir avec le soin raisonnablement attendu de qui exerce ce rôle. Compromis pragmatique, qui a marché des siècles. Il marchait parce que l’écart entre le savoir possible et la décision nécessaire était comblé par l’étude et l’expérience. Aujourd’hui cet écart n’est plus comblable. Pas un défaut d’engagement : un écart structurel, produit par la complexité de l’objet, pas par l’inadéquation du sujet.
La législation européenne récente l’intuitionne, sans le déclarer. CRA, PLD, AI Act : tous tentent de reconstruire des chaînes de responsabilité dans un contexte où ces chaînes sont physiquement brisées. Avec des outils classiques : obligations de doc, évaluations de conformité, registres de risque. Tentatives sérieuses, souvent bienvenues. Mais elles reposent sur un présupposé silencieux : qu’il y a quelque part quelqu’un qui sait.
Le producteur doit documenter les risques de son produit. Mais il ne connaît pas les dépendances transitives de son code. L’importateur doit vérifier la conformité. Mais la conformité est définie par rapport à des standards décrivant des propriétés que personne ne peut vérifier en pratique. L’utilisateur doit donner un consentement éclairé. Mais l’information nécessaire à un consentement véritable demanderait des compétences que même l’auteur du logiciel ne possède pas.
Pas du cynisme. La description précise d’une situation qu’on a créée pas à pas, en bonne foi, en résolvant chaque problème immédiat et en ajoutant à chaque fois un gramme d’opacité au système global.
Le mythe de la spécialisation
Une réponse fréquente : la spécialisation résout le problème. Personne n’a besoin de tout comprendre, il suffit que chacun comprenne son morceau, et l’ensemble marchera. C’est la division du travail appliquée au savoir, et c’est attractif parce que ça permet d’éviter la question de fond.
Mais ça ne marche pas. Parce que les frontières entre « morceaux » sont arbitraires et perméables. Un problème de sécurité traverse toutes les couches. Une exigence normative coupe transversalement frontend, backend, infra, fournisseurs tiers. Une décision d’archi prise il y a cinq ans dans un contexte qui n’existe plus contraint aujourd’hui des choix que celui qui la prit n’aurait pu imaginer.
La spécialisation marche quand les composants sont vraiment indépendants. Le software ne l’est pas. Il est fait de dépendances, au sens littéral : chaque partie dépend d’autres parties, et le comportement de l’ensemble n’est pas déductible de celui des parties. C’est ce que la théorie des systèmes appelle émergence, et l’émergence est précisément l’adversaire de la spécialisation. Le bug le plus tordu vit toujours dans l’espace entre les spécialisations, là où personne ne regarde parce que personne ne pense que c’est son territoire.
L’incompétence du législateur
Un cas particulier mérite attention, pas par esprit accusatoire mais parce qu’il est structurellement éclairant : l’incompétence de qui écrit les normes.
Un législateur qui rédige des règles sur le software est dans la même position épistémologique que tout le monde : il ne peut pas comprendre le système dans son ensemble. Mais à la différence d’un dev ou d’un architecte, il n’a même pas la connaissance partielle de l’usage quotidien. Il opère sur des descriptions de descriptions, sur des abstractions d’abstractions, médiées par des consultants qui à leur tour médient le savoir de spécialistes.
Pas un argument contre la régulation. Au contraire : un argument sur la nature de la régulation possible. Encadrer ce qu’on ne comprend pas entièrement n’est pas un échec, c’est la condition de départ. La question n’est pas si le législateur est compétent — il ne peut pas l’être au sens plein, et pas par sa faute. La question est si les normes qu’il produit sont assez robustes pour fonctionner malgré l’incompétence structurelle de qui les a écrites, de qui doit les appliquer, de qui doit les vérifier.
Parfois la réponse est oui. Le RGPD, avec ses limites, a introduit un principe de précaution qui marche précisément parce qu’il n’exige pas une compréhension technique : il traite les données personnelles comme dangereuses, indépendamment du fait qu’on saisisse les mécanismes spécifiques du danger. Une norme conçue pour l’incompétence — et qui marche mieux que beaucoup de normes qui présupposent la compétence.
Socrate dans le cycle de dev
Une phrase est attribuée à Socrate avec la fréquence et l’imprécision réservées à toutes les phrases trop utiles : « je sais que je ne sais rien ». Citée comme geste d’humilité, parfois comme coquetterie. Mais dans sa version la plus radicale, celle de l’Apologie platonicienne, le point est plus inconfortable : Socrate ne dit pas simplement que sa connaissance est limitée. Il dit que celui qui croit savoir est dans une condition pire que celui qui sait qu’il ne sait pas, parce qu’à l’ignorance il ajoute l’illusion.
Appliquée au présent technologique, la thèse socratique prend un poids que Platon n’aurait pu imaginer. L’industrie du software est bâtie sur une double illusion de savoir : celle de qui construit (qui croit contrôler) et celle de qui utilise (qui croit comprendre). Toutes deux fonctionnelles. Sans la première, personne n’écrirait de code, parce que l’honnêteté intégrale serait paralysante. Sans la seconde, personne n’utiliserait de software, parce que le consentement éclairé authentique produirait un refus de masse.
Nous fonctionnons grâce à une suspension volontaire de l’incrédulité épistémologique. Pas autrement que la finance, ou la politique, ou tout autre système complexe où la confiance remplace la compréhension.
Différence quand même. Finance et politique ont développé une conscience institutionnelle de leur fragilité épistémologique. Les banques centrales existent parce qu’on sait que le système financier ne s’autorégule pas. Les constitutions existent parce qu’on sait que le pouvoir ne s’autolimite pas. L’informatique n’a rien d’équivalent. Pas d’institutions conçues pour gérer le fait que personne ne sait. Standards, best practices, frameworks de certification : tous outils qui présupposent la possibilité du savoir au lieu d’affronter son impossibilité.
Décider sans savoir
La condition quotidienne de qui travaille dans la techno : décider sans savoir. Pas au sens dramatique d’un pari aveugle, mais au sens ordinaire et un peu usant de qui prend chaque jour des décisions aux conséquences pluriannuelles, basées sur des informations qu’on sait incomplètes, dans des contextes qu’on sait destinés à changer, pour des exigences qu’on sait provisoires.
Une estimation est une déclaration de probabilité subjective vendue comme prévision. Un choix d’archi est un acte de foi dans la stabilité de conditions qui ne le sont pas. Un refactoring est un pari sur le fait que le coût présent sera payé par des bénéfices futurs que personne ne peut garantir. Chaque sprint est un exercice d’épistémologie appliquée sous contrainte temporelle, mené par des gens qui n’ont pas étudié l’épistémologie et qui ne sont pas payés pour réfléchir aux conditions de possibilité de leur savoir, mais pour produire.
Pas une dénonciation. Une description. Et le point n’est pas que les choses devraient aller autrement : c’est qu’elles ne peuvent pas aller autrement. L’incompétence structurelle n’est pas un problème à résoudre. C’est la condition dans laquelle nous opérons, et qui durera tant qu’on construira des systèmes dont la complexité excède la capacité de compréhension de qui les construit.
La question n’est pas comment éliminer l’incompétence. C’est comment l’habiter.
Habiter l’incompétence
Si la compétence, au sens classique de maîtrise complète, n’est plus atteignable, alors ce qu’on appelle de ce nom est devenu autre chose. Pas un savoir, mais un savoir-faire en l’absence de savoir. Une forme de sagesse pratique plus proche de la phronésis aristotélicienne que de l’épistémè : non la connaissance des causes premières, mais la capacité à bien agir dans des situations particulières et incertaines.
Le bon technicien aujourd’hui n’est pas celui qui sait le plus. C’est celui qui gère le mieux son ignorance. Qui sait où sont les limites de ce qu’il comprend, qui sait demander, quand s’arrêter, comment construire des systèmes qui échouent de façon prévisible plutôt que catastrophique. Ce sont des compétences, mais sur sa propre incompétence. Des méta-compétences, si on accepte un mot moche pour une idée importante.
Et là, un paradoxe à regarder en face. La culture pro du software récompense le savoir et punit le non-savoir. Qui admet ne pas comprendre perd en crédibilité. Qui dit « je ne sais pas » en réunion est perçu comme faible. Qui estime honnêtement est puni dans la comparaison avec qui estime avec optimisme. Tout le système d’incitations est conçu pour masquer l’incompétence plutôt que la gérer, ce qui produit le résultat inverse : incompétence non reconnue, non gérée, non métabolisée. Incompétence dangereuse.
Une culture pro mature ferait l’inverse. Elle partirait du fait que personne ne comprend le système entier, et bâtirait processus, outils, institutions conçus pour fonctionner dans cette condition. Pas une utopie : c’est de l’ingénierie de l’ignorance, et c’est exactement ce qu’on fait quand on écrit des tests automatisés (on vérifie parce qu’on ne se fie pas à sa compréhension), quand on fait des code reviews (on cherche les erreurs que notre angle mort nous cache), quand on adopte le principe de moindre privilège (on limite le dommage que notre ignorance peut causer).
Pas des palliatifs. Les pratiques les plus sophistiquées que l’industrie ait produites, et toutes, à la racine, des techniques de gestion de l’incompétence. Personne ne les nomme ainsi parce que le nom serait gênant. Mais elles le sont.
L’honnêteté comme méthode
Peut-être la seule réponse disponible à l’incompétence structurelle n’est pas une solution mais une attitude : l’honnêteté épistémologique comme pratique quotidienne. Savoir qu’on ne sait pas, non comme formule creuse, mais comme point de départ opératoire de chaque décision.
Pas la paralysie. Décider en sachant qu’on décide à l’aveugle, et bâtir des filets de sécurité proportionnés à cette conscience. Documenter non seulement ce qu’on a fait, mais pourquoi et sur quels présupposés — parce que ces présupposés se révéleront faux et que les suivants auront besoin de comprendre non la solution, mais le raisonnement qui l’a produite. Cesser de traiter les estimations comme des promesses et les architectures comme des monuments.
Pas une proposition révolutionnaire. La description de ce que les meilleurs font déjà, souvent en silence, souvent à contre-courant de la culture qui les entoure. L’incompétence structurelle n’est pas un ennemi à vaincre. C’est le terrain sur lequel nous marchons, et le seul choix disponible est entre marcher les yeux ouverts ou les yeux fermés.
Nous, comme espèce, avons construit un monde que nous ne sommes pas capables de comprendre. Pas une tragédie. Peut-être la chose la plus humaine que nous ayons jamais faite.
Ce qu'il faut retenir
L’incompétence est structurelle, pas personnelle : un projet logiciel moyen repose sur des milliers de dépendances transitives jamais vérifiées.
La spécialisation ne sauve pas : les bugs les plus tordus vivent dans l’espace entre les spécialisations, là où personne ne regarde.
Le RGPD marche parce qu’il est conçu pour l’incompétence (les données sont dangereuses par défaut) ; les normes qui présupposent la compétence échouent.
Tests automatisés, code reviews, principe de moindre privilège : ce sont toutes des techniques d’ingénierie de l’ignorance — personne ne les appelle ainsi parce que le nom serait gênant.
Le bon tech aujourd’hui n’est pas qui sait le plus, mais qui gère le mieux son ignorance : méta-compétence, phronésis aristotélicienne plus qu’épistémè.
Questions & réponses
Pourquoi l'incompétence est-elle structurelle, pas personnelle ?
Parce que la complexité cumulée des objets techniques modernes — un stack logiciel avec des millions de dépendances transitives, un modèle IA avec des milliards de paramètres, une infra cloud avec des milliers de services interconnectés — a dépassé la capacité cognitive humaine. Ce n’est pas une affaire de formation ou d’intelligence : il est physiquement impossible qu’une personne maîtrise toute la chaîne causale d’un artefact qu’elle contribue à construire.
Comment en est-on arrivé là ?
Par stratification, pas par fracture. Chaque niveau d’abstraction ajouté au-dessus du précédent résolvait un problème et en créait un autre : rendre le niveau inférieur opaque. Le développeur d’application ne connaît pas vraiment le framework ; qui connaît le framework ne connaît pas le runtime ; qui connaît le runtime ne connaît pas le microcode du processeur. Personne ne connaît la chaîne entière de dépendances qu’une seule commande d’install télécharge.
Si personne ne comprend le système, qui est responsable quand ça tourne mal ?
C’est la question que la régulation européenne (CRA, PLD, AI Act) tente de formaliser ex-post : la responsabilité passe au producteur indépendamment de la compréhension fine de l’objet. Mais c’est une réponse juridique, pas épistémologique. Le concept classique de « compétence technique comme prémisse de la responsabilité » ne tient plus — on reconstruit des systèmes de responsabilité sur des fondations qui n’existent plus.
Que faire concrètement si la compréhension complète est impossible ?
Cesser de prétendre l’avoir. Trois mouvements : observabilité agressive — si on ne peut pas comprendre le système, on doit au moins le mesurer en temps réel ; équipes structurellement multidisciplinaires — la compétence devient collective ; remplacer la doc « comment ça marche » par des contrats comportementaux vérifiables, c’est-à-dire « ce qu’on garantit » plutôt que « ce qu’il y a dedans ».
L'auteur
