Personne ne sait comment fonctionne l’ensemble du système

• Les systèmes technologiques modernes ont évolué vers des structures si complexes qu’aucun individu ne peut en comprendre l’ensemble
• Avec l’essor du développement logiciel et de l’usage de l’IA, les cas se multiplient où des développeurs construisent sans comprendre les mécanismes internes
• Simon Wardley souligne les risques de construire des systèmes sans les comprendre, Adam Jacob observe que l’IA transforme la manière de développer, et Bruce Perens estime que la complexité a déjà dépassé les limites
• À travers l’exemple du système téléphonique, Louis Bucciarelli montre que la technologie est imbriquée à plusieurs niveaux, au point que personne ne peut parvenir à une compréhension complète
• L’article insiste sur le fait que l’IA accentue cette complexité, mais qu’en réalité les humains manipulent depuis longtemps la technologie avec une compréhension seulement partielle

---

Complexité technique et limites de la compréhension

• Depuis le déclin de Twitter, les discussions sur la compréhension technique et la complexité se sont intensifiées sur LinkedIn
  • Les publications de Simon Wardley, Adam Jacob et Bruce Perens y sont présentées comme liées par un thème commun
• Wardley met en garde contre le danger de construire des systèmes sans en connaître les principes fondamentaux
  • Le terme « Magic » désigne de façon critique des frameworks qui masquent le fonctionnement interne, Ruby on Rails étant cité comme exemple emblématique
• Jacob souligne que l’IA est en train de transformer en profondeur la façon de développer des logiciels
  • L’IA améliore l’efficacité, mais tend aussi à faire travailler les développeurs sans qu’ils comprennent l’infrastructure sous-jacente
• Perens affirme que la situation redoutée par Wardley est déjà devenue réalité
  • En raison de la complexité des CPU et des systèmes d’exploitation modernes, beaucoup de développeurs comprennent mal leur fonctionnement réel

Le cas du « téléphone » chez Louis Bucciarelli

• Dans son livre de 1994 Designing Engineers, Bucciarelli traite des limites de la culture technique
  • La plupart des gens sont incapables d’expliquer le fonctionnement d’un téléphone au niveau physique
  • Des éléments à plusieurs niveaux s’y entremêlent : routage du réseau, traitement du signal, transmission par satellite, exploitation par les entreprises et structures réglementaires
• Il en arrive à la conclusion que « personne ne sait complètement comment fonctionne son téléphone »
  • Cela symbolise le fait que les systèmes techniques complexes dépassent la capacité humaine de compréhension totale

Entretiens techniques et « limites du savoir »

• L’auteur se remémore une conversation avec Brendan Gregg à l’époque où il travaillait chez Netflix
  • Gregg explique qu’en entretien, il évaluait les limites du savoir des candidats et leur réaction face à celles-ci
  • Il menait ses entretiens en partant du principe que « personne ne comprend entièrement l’ensemble du système »
• Cette approche montre que la capacité à reconnaître ce qu’on ne sait pas compte autant que les compétences techniques elles-mêmes

La nature de la complexité et l’impact de l’IA

• Les points de vue de Wardley, Jacob, Perens et Bucciarelli révèlent, à différents niveaux, le caractère inévitable de la complexité
  • Wardley : le risque de construire sans comprendre
  • Jacob : l’efficacité et la mise à distance apportées par l’IA
  • Perens : la réalité d’une complexité déjà bien présente
  • Bucciarelli : l’impossibilité de comprendre le système dans sa totalité
• L’article reconnaît que l’IA aggravera ce problème, tout en rappelant une réalité ancienne : les humains traitent depuis longtemps la technologie avec une compréhension partielle

Résumé des discussions des lecteurs

• Dans les commentaires, beaucoup expriment l’inquiétude que l’IA affaiblisse l’apprentissage et la compréhension
  • Certains affirment que « les LLM écrivent le code à notre place, ce qui rompt la chaîne de compréhension »
  • Wardley explique qu’« auparavant, la compréhension se maintenait dans une chaîne hiérarchique, mais les LLM suppriment cette chaîne »
• D’autres lecteurs rétorquent qu’il est prématuré d’affirmer que « les avantages de l’IA sont supérieurs à ses risques »
• Dans l’ensemble, la perte de compréhension technique à l’ère de l’IA et la rupture de l’apprentissage ressortent comme les principaux enjeux

[GN⁺]

Réactions sur Hacker News

• Ce qui m’inquiète dans la programmation actuelle, c’est la montée du « développement de couche intermédiaire », où l’on ne comprend ni l’étage du dessus (l’objectif du produit) ni celui du dessous (la manière dont il est implémenté)
  Avant, on pouvait ne pas connaître le métier, mais on comprenait au moins le sens du code ; maintenant, l’ambiance semble dire qu’on n’a même plus besoin de savoir comment le code fonctionne
  À force d’utiliser Claude, j’ai l’impression de perdre peu à peu ma conscience du contexte. Dans une culture de développement où tout s’arrête dès que les tests passent et que le bouton fonctionne, j’ai l’impression de ne plus rien avoir à apprendre ni à apporter

  • On insiste sur la notion de « ownership », mais dès qu’on essaie vraiment de prendre l’initiative, on se heurte aux restrictions d’accès et au manque d’information
    C’est particulièrement vrai dans les grandes entreprises, où la transparence fait défaut. Il m’est déjà arrivé de travailler tard pour tenir une échéance, alors que le calendrier avait été repoussé sans qu’on me le dise
    Si l’on me traite comme un simple outil, alors je n’assumerai que ce rôle. Mais si l’on veut une vraie ownership, il faut une place à la table des décisions
  • À l’inverse, j’ai l’impression que Claude a au contraire amélioré ma capacité de concentration
    Avant, je perdais du temps sur des tâches de configuration répétitives ; maintenant, je peux me concentrer uniquement sur les fonctionnalités essentielles. Du coup, j’arrive mieux à garder toute l’architecture en tête
  • Ce phénomène ressemble aussi à l’automatisation de l’agriculture. Aujourd’hui, il suffit de rester assis sur un tracteur et la machine fait tout. Au final, l’humain n’est plus qu’un poids pour le capteur de siège
  • J’aimerais que Claude prenne en charge non pas le développement entièrement automatisé, mais plutôt une édition de code interactive centrée sur de petites modifications
    Par exemple, sélectionner quelques lignes dans l’IDE puis dire à voix haute « modifie cette partie comme ça », avec application immédiate
    Si la vitesse est suffisante, le contrôle à la voix avec la souris pourrait aussi être un excellent outil d’accessibilité
  • En réalité, ce problème existe depuis longtemps. Le dependency hell en est l’exemple type
    Je pense même que les LLM pourraient au contraire réduire ce genre de complexité. J’aime les abstractions raisonnables, mais je n’aime pas ignorer totalement ce qu’il y a à l’intérieur

• Ce texte parle du fait que les gens utilisent des abstractions (abstraction) sans en connaître les rouages
  Mais c’est une évolution naturelle. Quelqu’un a conçu cette abstraction et l’a rendue utilisable par la couche supérieure
  Le raisonnement consistant à dire « puisque je ne connais pas le driver Wi‑Fi, je peux aussi ne rien comprendre à mon code » ne tient pas

  • Le problème, c’est qu’on risque maintenant de voir la plupart des gens perdre la capacité à créer de nouvelles abstractions
    Autrefois, on développait sa pensée en manipulant directement la « complexité nécessaire » ; aujourd’hui, on se contente souvent de faire le tuyau entre deux éléments
  • Le code produit par les LLM est souvent trop verbeux, ce qui allonge le temps de revue
    La solution consiste à envelopper l’abstraction dans un DSL (langage spécifique au domaine) plutôt que dans un langage généraliste. Pour du SaaS, je trouve qu’une approche DSL-first est meilleure qu’une approche API-first
  • En réalité, la culture du Clean Code et de l’OOP avait déjà provoqué des pertes de performances à cause d’une abstraction excessive
    Je ne pense pas que l’IA fasse pire. L’essentiel est de comprendre les abstractions sur lesquelles on s’appuie

• C’est en fait l’arbre de dépendances qui cause le plus gros des problèmes
  Rien qu’en regardant un projet Node.js, on voit des centaines de packages dépendants. Dans la plupart des cas, ce n’est pas grave de ne pas connaître leur fonctionnement interne, mais cela devient risqué quand les interfaces cassent souvent
  Beaucoup d’équipes ne suivent ni les EOL (fin de support) ni les vulnérabilités. En pratique, on ne sait même pas toujours répondre à la question : « Est-ce que c’est encore maintenu ? »

  • L’idéal serait de surveiller cela avec des outils SBOM/SCA
    Mais même avant l’IA, beaucoup de projets se retrouvaient déjà dans le dependency hell à cause de conflits de versions

• Les gens n’ont pas besoin de tout savoir, mais je pense que l’ignorance qui fait perdre les bases est dangereuse
  Si l’on prend l’exemple de la cuisine, on n’a pas besoin de cultiver le blé, mais si l’on ne sait même pas cuire un œuf, il y a un problème
  Si les entreprises standardisent et préparent toute la nourriture à notre place, faut-il y voir un progrès ou un recul ?

  • La plupart des gens n’ont pas besoin de savoir chasser ni cultiver, parce que la chaîne d’approvisionnement est suffisamment distribuée et redondante
    Si un jour les robots remplacent totalement la production alimentaire, ne pas savoir cuisiner ne posera peut-être plus aucun problème
  • La ligne de partage entre ce qui est acceptable et ce qui devient dangereux varie selon les personnes
  • Certains rétorquent : « Pourquoi serait-ce dangereux de ne pas savoir cuire un œuf ? »
    Après tout, il ne faut pas non plus connaître la science des matériaux pour éviter toute dépendance, n’est-ce pas ?

• Les couches basses comme les instructions CPU et les caches sont rigoureusement validées et documentées depuis des décennies
  En revanche, le code généré par les LLM n’est pas aussi fiable et peut nécessiter un refactoring dès demain

• Je ne connais peut-être pas les détails de fonctionnement des couches inférieures, mais je comprends comment fonctionne mon code
  Ne pas connaître l’étage du dessous et ne pas connaître la zone dont on est responsable sont deux choses totalement différentes

  • Autrefois, même dans les systèmes complexes, il y avait quelqu’un qui connaissait chaque partie
    Aujourd’hui, le vrai danger, c’est l’apparition de fragments de code que personne ne comprend

• Je ne suis pas d’accord avec l’idée que l’IA aggrave la situation
  Au contraire, les LLM ont assimilé presque tout le savoir disponible, et peuvent donc expliquer de façon structurée des questions comme « comment fonctionne un téléphone ? »
  Les humains ont la limite de ne même pas savoir ce qu’ils ignorent, alors que les LLM couvrent presque tout ce qui a été exprimé sous forme de langage
  Bien sûr, ils restent faibles en raisonnement et en génération de code, mais leur capacité à intégrer les connaissances est supérieure à celle des humains

  • Mais un LLM ne « sait » pas réellement : il génère quelque chose de plausible
    Il ne peut pas remplacer une vraie documentation. En revanche, il est très utile pour indiquer, comme un humain, « ce qu’il faut aller chercher »

• Une bonne conception consiste à faire en sorte que le système fonctionne sans qu’on ait à tout connaître
  Le problème n’est pas le système créé par l’IA, mais le fait que nous connaissions encore mal ses modes de défaillance et ses limites
  Au final, l’essentiel est notre capacité de conception organisationnelle pour coordonner humains et IA afin de construire le système nécessaire

• Je ne connais pas parfaitement l’intérieur d’un ordinateur, mais je résous des problèmes grâce à une automatisation pratique par scripts
  Sans étudier l’assembleur x86, on peut gérer une infrastructure en Python
  Mais je pense que les développeurs expérimentés ont la responsabilité de transmettre ce savoir. J’aimerais moi aussi tenir ce rôle un jour

  • Si l’on ne jure que par le « pragmatisme », on finit par tomber dans une spécialisation excessive
    Il ne faut pas perdre sa curiosité, et il faut aller parler activement avec les développeurs plus expérimentés
  • Quand on essaie d’enseigner les bases, on entend souvent : « ce n’est pas nécessaire »
    Mais il est frustrant de voir à quel point on ignore, malgré tous les rappels, l’importance d’une compréhension fondamentale
  • À titre de ressource d’apprentissage, il existe par exemple un site comme cpu.land

• Je suis réellement capable de répondre à des questions du type « que se passe-t-il quand on saisit une URL ? »
  J’ai travaillé comme technicien réacteur sur sous-marin dans la marine américaine, où j’ai appris aussi bien la théorie de l’électronique que le dépannage de systèmes
  Ensuite, en me reconvertissant dans l’IT, j’ai gardé la même attitude : aller au fond des choses à travers la documentation et l’expérimentation
  Grâce à cette habitude, le fait de relier des connaissances disparates m’aide énormément à résoudre les problèmes
  La page Wikipédia sur le VMEbus peut aussi être utile

  • J’ai eu à peu près la même réaction. Je peux expliquer la plupart de ces exemples au tableau, de mémoire
    Cela dit, je suis sans doute un cas à part, car je supporte mal de ne pas savoir
  • La profondeur de compréhension varie. Un développeur web peut connaître la pile réseau, mais le monde analogique des signaux radio relève encore d’un autre niveau