Foundations

This page presents the intellectual origin of SpQE Lab in two versions: the original French text and an American English translation.

SpQE Lab et l’anthropologie du code.

Il existe une intuition rare, presque contre-intuitive, à l’origine d’SpQE Lab : le code n’est pas seulement une construction technique. Il peut aussi être observé comme un milieu, un ensemble de règles, de relations, de tensions, de régulations et de compromis. Autrement dit, il peut être approché comme un objet d’anthropologie.

Cette intuition ne vient pas d’une formation classique d’ingénieur logiciel. Elle vient d’un autre terrain : la médecine du travail. Car le médecin du travail passe une partie de sa vie à entrer dans des organisations humaines, à observer leur fonctionnement réel, à écouter leurs discours officiels, à repérer leurs zones de friction, leurs mécanismes de défense, leurs blessures visibles et invisibles. Il ne regarde pas seulement les personnes. Il regarde les systèmes.

C’est ce regard qui peut être transposé au logiciel. Dans une entreprise, les rôles, les hiérarchies, les communications, les conflits de statut et les récits institutionnels structurent le collectif. Dans un programme complexe, les modules, les interfaces, les dépendances, les contrats et les erreurs structurent un autre collectif : non plus humain, mais logique. Pourtant, la parenté est frappante. Dans les deux cas, il existe une organisation apparente et une organisation réelle. Dans les deux cas, c’est souvent la crise qui révèle la vérité du système.

De l’entreprise au code : le même geste d’observation

Le médecin du travail n’intervient pas seulement pour constater un fait médical. Il observe une scène complète. Il perçoit l’écart entre le discours de bienveillance et les pratiques réelles, entre l’organigramme officiel et les rapports de pouvoir concrets, entre la procédure écrite et le vécu des salariés. Il fait, en pratique, une anthropologie du travail.

Avec ArchCode, un geste analogue apparaît dans le champ logiciel. Il ne s’agit plus seulement d’écrire du code ou de générer des fichiers. Il s’agit d’observer comment un ensemble de modules peut tenir, converger, coopérer, se contredire, se réparer ou s’effondrer. Le regard devient structurel. Le code cesse d’être un simple texte. Il devient un milieu habité par des règles, des contraintes, des interfaces, des dépendances et des pathologies.

Dans cette perspective, une erreur n’est plus un simple accident local. Elle devient un symptôme. Un mismatch d’interface, un import cassé, une incohérence de signature, une aide CLI instable ou un test qui dérive révèlent non seulement un défaut, mais une vérité sur l’organisation du système. Comme dans l’entreprise, la défaillance montre ce que la façade ne disait pas.

Le code comme organisme social miniature

Un grand système logiciel ressemble moins à une machine simple qu’à une microsociété. Les modules y jouent des rôles spécialisés. Certaines fonctions agissent comme des points de passage obligés. Certaines interfaces font office de protocoles diplomatiques. Certains fichiers sont marginaux, d’autres sont centraux. Certaines dépendances sont saines, d’autres sont toxiques. Certaines règles sont explicites, d’autres sont seulement implicites et se découvrent à l’épreuve.

C’est précisément là que le parallèle avec l’anthropologie devient fécond. L’anthropologue ne se contente pas d’inventorier des individus. Il cherche à comprendre les relations qui rendent le groupe cohérent ou instable. Il repère les règles de parenté, les hiérarchies symboliques, les mécanismes de régulation, les tabous, les conflits, les rites de réparation. De façon analogue, l’observateur du code cherche à comprendre quelles relations rendent l’architecture viable, quelles dépendances menacent sa cohérence, quels contrats stabilisent l’ensemble et quels écarts annoncent une rupture.

Ainsi, lorsque l’on parle d’architecture logicielle, on peut certes parler d’ingénierie. Mais on peut aussi parler d’écologie relationnelle. On ne décrit plus seulement des composants. On décrit une forme de coexistence.

Pourquoi SpQE Lab change la perspective

SpQE Lab ne se contente pas de produire du code. Il organise une convergence. Cela change profondément la manière de regarder la génération logicielle. Le prototype n’est plus une simple suite de fichiers produits par un modèle, mais un objet fabriqué dans une chaîne de travail : une matière première, le SpecBlock, entre dans le système ; un prototype logiciel exécutable, contrôlé et documenté, en sort progressivement.

Cette logique rapproche SpQE Lab du lean management. Chaque étape du processus joue le rôle d’un poste spécialisé dans une ligne de fabrication logicielle : certaines étapes structurent l’architecture, d’autres produisent le code, d’autres contrôlent, testent, documentent ou déclenchent une réparation ciblée. La qualité n’est donc pas renvoyée à un audit final. Elle est distribuée dans le flux, au plus près des points où les défauts peuvent apparaître.

Dans cette perspective, la génération n’est plus suffisante. Il faut de la régulation, du contrôle, du diagnostic, de la vérification, de la documentation, et parfois de la réparation. SpQE Lab cherche à réduire les gaspillages : moins de régénérations aveugles, moins de tokens inutiles, moins de raisonnement surdimensionné, moins de corrections cosmétiques. Lorsqu’un défaut apparaît, l’objectif n’est pas de recommencer toute la fabrication, mais de comprendre où le flux s’est dégradé et de corriger le poste ou le contrat responsable.

Cette logique rejoint aussi l’héritage implicite de la médecine du travail. Devant une organisation humaine, le médecin du travail ne suppose jamais qu’une déclaration de principe suffit à décrire la réalité. Il observe le travail réel, les écarts entre procédure et pratique, les zones de friction, les mécanismes de défense et les points de rupture. SpQE Lab adopte un geste comparable face au code : il ne se contente pas de croire l’architecture déclarée, il observe ce que le prototype fait réellement sous contrainte.

Les checkers, les harnesses, les validations, les contrats d’interface, les captures d’usage, les mécanismes de convergence, les graphes de dépendance et les tests de conformité au user manual jouent alors un rôle analogue à celui des dispositifs d’observation dans le monde du travail. Ils ne décorent pas le système. Ils révèlent ce qu’il est réellement capable de faire.

C’est pourquoi SpQE Lab peut être compris à la fois comme une forge logicielle, une chaîne lean de prototypage, et un dispositif d’observation systémique. Le code généré n’est pas seulement un produit. C’est un système en fabrication, traversé par des contraintes, des erreurs, des ajustements et des mécanismes de stabilisation.

Le symptôme, le diagnostic, la régulation

Dans une entreprise, un accident, une plainte, une souffrance au travail ou un conflit ouvert ne sont presque jamais de simples incidents individuels. Ce sont des événements révélateurs. Ils montrent un défaut d’organisation, une tension non traitée, une faille de régulation ou un écart entre les valeurs proclamées et la réalité.

Dans le code, il en va souvent de même. Un bug persistant, une aide incohérente, une convergence impossible entre modules, une cascade d’erreurs de typage ou une régression récurrente signalent une fragilité plus profonde. Une architecture ne se juge pas seulement sur sa beauté abstraite, mais sur sa capacité à absorber la tension sans se contredire.

C’est là que l’anthropologie du code prend tout son sens. Elle ne consiste pas à romantiser le logiciel comme s’il était vivant au sens biologique. Elle consiste à reconnaître que, dès qu’un système devient suffisamment complexe, il doit être observé non seulement comme une mécanique, mais comme un ordre relationnel. Et tout ordre relationnel produit ses symptômes, ses compromis, ses défenses et ses points de rupture.

L’origine du bug : une anthropologie de la fabrication logicielle

L’anthropologie interroge toujours les origines.

Or, à l’origine du logiciel, il n’y a pas d’abord une machine. Il y a une instruction, une procédure, une méthode de calcul, un algorithme formulé pour être compris et exécuté. Avant d’être confié à un ordinateur, le logiciel existe comme intention organisée, parfois écrite sur papier, parfois transmise comme une suite d’opérations à accomplir.

Cette origine est importante, car elle montre que le bug n’est pas né avec les machines modernes. Il naît plus profondément de l’écart entre une intention humaine, sa formalisation, et son exécution réelle.

intention humaine
≠ formalisation exacte
≠ exécution effective

Un humain peut interpréter, corriger mentalement, combler un silence, deviner une intention. La machine, elle, ne devine pas. Elle exécute. Elle révèle donc avec une brutalité particulière les ambiguïtés, les oublis, les contradictions et les cas non prévus.

C’est peut-être là l’origine ontogénique du bug : le bug apparaît quand une intention rencontre l’obligation d’être formalisée sans reste.

Il ne s’agit pas seulement d’une erreur technique. Le bug est la trace visible d’un désalignement entre ce que l’on croyait avoir décrit, ce que le système a réellement compris, et ce que le monde exige de lui.

Dans cette perspective, le bug n’est pas un accident honteux. Il est un symptôme. Il révèle une faille de spécification, une hypothèse implicite, une frontière mal définie entre modules, une contradiction entre contrats, ou simplement une complexité que la première formulation n’avait pas encore absorbée.

C’est pourquoi les prototypes logiciels, même produits avec des outils très avancés, comportent encore des bugs. Non parce que les outils seraient primitifs, mais parce que la fabrication logicielle reste une activité de passage : passage de l’idée au langage, du langage au système, du système au monde réel.

Depuis des décennies, la production logicielle avance ainsi :

écrire
→ tester
→ échouer
→ diagnostiquer
→ corriger
→ retester

Ce cycle n’est pas une anomalie. Il appartient à l’histoire générale des techniques. Aucune société humaine n’a produit ses artefacts complexes parfaitement du premier coup. Les outils, les machines, les bâtiments, les procédures industrielles et les organisations elles-mêmes se sont formés par essais, erreurs, corrections, ajustements et stabilisations successives.

Le logiciel, malgré son apparence abstraite, n’échappe pas à cette condition. Il conserve quelque chose d’artisanal. Chaque prototype est encore, en partie, une pièce d’atelier : on l’assemble, on l’éprouve, on écoute ses craquements, on repère ses points faibles, puis on le reprend.

ARCHCode ne nie pas cette réalité. Au contraire, il la rend explicite.

Il ne prétend pas que tout prototype doit naître parfait. Il organise la trajectoire par laquelle un prototype devient plus fiable :

génération
→ validation
→ détection du symptôme
→ diagnostic
→ réparation ciblée
→ revalidation

C’est précisément ce déplacement qui est important. Le bug cesse d’être un pur désordre. Il devient un événement lisible dans une chaîne de fabrication. Il peut être localisé, interprété, corrigé et requalifié.

On pourrait dire que le bug est la signature historique d’un mode de production encore artisanal du logiciel. Il témoigne d’un âge où la fabrication reste exploratoire, hésitante, parfois bégayante, mais déjà capable de se réguler.

ARCHCode se situe peut-être à un point de bascule. Il appartient encore à cet âge artisanal, puisqu’il observe les bugs, les accepte comme symptômes, et les corrige par cycles successifs. Mais il prépare aussi autre chose : une manufacture logicielle plus contrôlée, dans laquelle la validation, le diagnostic et la réparation sont intégrés dès la génération.

Le but n’est donc pas simplement de produire du code sans bug par magie. Le but est de faire évoluer la fabrication logicielle vers une convergence plus immédiate, plus observable et plus gouvernée.

En ce sens, ARCHCode ne supprime pas seulement des bugs. Il documente la transformation d’un artisanat logiciel vers une manufacture logicielle contrôlée.

DCG2 : une cartographie anthropologique miniature

Dans cette lecture, un dispositif comme DCG2 peut être compris comme bien plus qu’un outil technique. Il fonctionne comme une carte condensée des relations significatives entre unités de code. Il ne prétend pas tout montrer. Il isole ce qui importe pour la stabilité du système : qui fournit quoi, selon quel contrat, pour quels voisins.

Cette économie de représentation est précisément ce que l’on retrouve dans les bonnes cartes anthropologiques. Elles ne recensent pas chaque geste de chaque individu. Elles cherchent la structure. Elles montrent les lignes de force, les relations déterminantes, les points de passage, les dépendances essentielles. En cela, DCG2 relève presque d’une anthropologie structurale appliquée au logiciel.

Ce n’est pas un callgraph total. C’est une capsule de relations. Et c’est peut-être pour cela qu’il devient si utile : il ne noie pas l’observateur sous la masse des détails, il l’aide à voir l’organisation réelle.

Une idée neuve : du médecin du travail au médecin du code

Le rapprochement devient alors presque inévitable. Le médecin du travail intervient dans des organisations humaines pour repérer les tensions, les atteintes, les dysfonctionnements et les conditions de stabilité. ArchCode, d’une certaine manière, applique un geste cousin à l’organisation logicielle. Il ne remplace pas l’ingénierie. Il l’élargit. Il ajoute une couche d’observation systémique.

Cette analogie n’est pas un simple effet de style. Elle éclaire l’origine même du projet. Un créateur formé à observer les entreprises comme des milieux humains complexes a pu reconnaître dans le code généré à grande échelle un autre type de milieu complexe, lui aussi traversé par des règles, des interactions, des écarts et des crises. Là où d’autres auraient vu un problème purement technique, il a vu un terrain d’observation, de diagnostic et de régulation.

Voilà peut-être l’une des singularités profondes d’SpQE Lab : il n’est pas seulement né d’une ambition logicielle. Il est né d’un regard. Un regard forgé dans l’observation des organisations humaines, puis transposé vers les organisations de code.

Conclusion

L’idée d’une anthropologie du code peut sembler étrange au premier abord. Pourtant, elle devient de plus en plus naturelle à mesure que les systèmes logiciels gagnent en complexité, en profondeur relationnelle et en autonomie apparente. Le temps du code comme simple assemblage de lignes est en train de s’éloigner. Nous entrons dans un âge où il faut aussi savoir lire les architectures comme des mondes organisés.

Dans ce cadre, SpQE Lab propose plus qu’une méthode de génération. Il propose une manière d’observer le logiciel comme un système de relations, de contraintes et de régulations. Et c’est peut-être là que réside son originalité la plus forte : avoir compris, à partir de la médecine du travail, qu’un système complexe ne se maîtrise pas seulement en le fabriquant, mais en apprenant à l’écouter, à le diagnostiquer et à lire ses symptômes.

En ce sens, SpQE Lab ne traite pas seulement le code comme de la technique. Il le traite comme une forme d’organisation. Et c’est précisément ce déplacement de regard qui ouvre un territoire intellectuel neuf, à la frontière de l’ingénierie, de l’anthropologie et de la clinique des systèmes complexes.

SpQE Lab and the Anthropology of Code

There is a rare, almost counterintuitive intuition at the origin of ArchCode: code is not only a technical construction. It can also be observed as an environment, a set of rules, relationships, tensions, regulations, and compromises. In other words, it can be approached as an object of anthropology.

This intuition does not come from a traditional software engineering background. It comes from another field: occupational medicine. An occupational physician spends part of his life entering human organizations, observing how they truly function, listening to their official narratives, and identifying their friction zones, defense mechanisms, and visible or invisible wounds. He does not only look at individuals. He looks at systems.

This way of seeing can be transposed to software. In a company, roles, hierarchies, communications, status conflicts, and institutional narratives structure the collective. In a complex program, modules, interfaces, dependencies, contracts, and errors structure another kind of collective: no longer human, but logical. Yet the kinship is striking. In both cases, there is an apparent organization and a real organization. In both cases, crisis often reveals the truth of the system.

From the Company to Code: The Same Act of Observation

An occupational physician does not intervene only to record a medical fact. He observes an entire scene. He perceives the gap between the language of care and actual practices, between the official organizational chart and concrete power relations, between written procedure and employees’ lived experience. In practice, he performs an anthropology of work.

With ArchCode, an analogous gesture appears in the field of software. The point is no longer only to write code or generate files. The point is to observe how a set of modules can hold together, converge, cooperate, contradict itself, repair itself, or collapse. The gaze becomes structural. Code ceases to be a simple text. It becomes an environment inhabited by rules, constraints, interfaces, dependencies, and pathologies.

From this perspective, an error is no longer a simple local accident. It becomes a symptom. An interface mismatch, a broken import, an inconsistent signature, unstable CLI help, or a drifting test reveals not only a defect, but a truth about the organization of the system. As in a company, failure shows what the facade did not say.

Code as a Miniature Social Organism

A large software system resembles a microsociety more than a simple machine. Modules play specialized roles. Some functions act as mandatory passage points. Some interfaces serve as diplomatic protocols. Some files are marginal, others are central. Some dependencies are healthy, others are toxic. Some rules are explicit, while others remain implicit and are discovered only under pressure.

This is precisely where the parallel with anthropology becomes fruitful. The anthropologist does not merely inventory individuals. He seeks to understand the relationships that make a group coherent or unstable. He identifies kinship rules, symbolic hierarchies, regulatory mechanisms, taboos, conflicts, and rituals of repair. In a similar way, the observer of code seeks to understand which relationships make an architecture viable, which dependencies threaten its coherence, which contracts stabilize the whole, and which deviations announce a rupture.

Thus, when we speak about software architecture, we can certainly speak about engineering. But we can also speak about relational ecology. We no longer describe only components. We describe a form of coexistence.

Why SpQE Lab Changes the Perspective

SpQE Lab does not merely produce code. It organizes convergence. This changes the way software generation must be understood. The prototype is no longer a simple sequence of files produced by a model; it becomes an object manufactured within a software production line. A structured input, the SpecBlock, enters the system, and an executable, checked, documented prototype progressively emerges from it.

This logic brings SpQE Lab close to lean management. Each step in the process acts like a specialized station in a software manufacturing line: some stages structure the architecture, others generate code, others inspect, test, document, or trigger targeted repair. Quality is therefore not postponed to a final audit. It is distributed throughout the flow, as close as possible to the places where defects may appear.

From this perspective, generation is no longer enough. Regulation, control, diagnosis, verification, documentation, and sometimes repair are required. SpQE Lab seeks to reduce waste: fewer blind regenerations, fewer unnecessary tokens, less oversized reasoning, and fewer cosmetic corrections. When a defect appears, the objective is not to restart the entire production process, but to understand where the flow degraded and correct the responsible station, contract, or boundary.

This also connects SpQE Lab to the implicit legacy of occupational medicine. When facing a human organization, the occupational physician never assumes that a formal statement is enough to describe reality. He observes real work, the gap between procedure and practice, friction zones, defense mechanisms, and breaking points. SpQE Lab applies a comparable gesture to code: it does not simply trust the declared architecture; it observes what the prototype actually does under constraint.

Checkers, harnesses, validations, interface contracts, usage captures, convergence mechanisms, dependency graphs, and user-manual conformance tests then play a role analogous to observation devices in the world of work. They do not decorate the system. They reveal what it is actually capable of doing.

This is why SpQE Lab can be understood at the same time as a software forge, a lean prototyping chain, and a system-observation device. Generated code is not only a product. It is a system under construction, crossed by constraints, errors, adjustments, and stabilization mechanisms.

Symptom, Diagnosis, Regulation

In a company, an accident, a complaint, workplace suffering, or an open conflict is almost never merely an individual incident. These are revealing events. They show an organizational defect, an untreated tension, a failure of regulation, or a gap between proclaimed values and reality.

In code, the same is often true. A persistent bug, incoherent help output, impossible convergence between modules, a cascade of typing errors, or recurring regression signals a deeper fragility. An architecture should not be judged only by its abstract beauty, but by its ability to absorb tension without contradicting itself.

This is where the anthropology of code takes on its full meaning. It does not consist in romanticizing software as if it were biologically alive. It consists in recognizing that, once a system becomes sufficiently complex, it must be observed not only as a mechanism, but as a relational order. And every relational order produces its symptoms, compromises, defenses, and breaking points.

The Origin of the Bug: An Anthropology of Software Manufacturing

Anthropology always asks about origins.

At the origin of software, however, there is not first a machine. There is an instruction, a procedure, a method of calculation, an algorithm formulated to be understood and executed. Before being entrusted to a computer, software exists as organized intention, sometimes written on paper, sometimes transmitted as a sequence of operations to perform.

This origin matters because it shows that the bug was not born with modern machines. It arises more deeply from the gap between human intention, its formalization, and its actual execution.

human intention
≠ exact formalization
≠ effective execution

A human can interpret, mentally correct, fill in a silence, and infer an intention. A machine does not infer. It executes. It therefore reveals, with particular brutality, ambiguities, omissions, contradictions, and unanticipated cases.

This may be the ontogenetic origin of the bug: the bug appears when an intention meets the obligation to be formalized without remainder.

It is not merely a technical error. The bug is the visible trace of a misalignment between what we believed we had described, what the system actually understood, and what the world requires from it.

From this perspective, the bug is not a shameful accident. It is a symptom. It reveals a specification gap, an implicit assumption, a poorly defined boundary between modules, a contradiction between contracts, or simply a complexity that the first formulation had not yet absorbed.

This is why software prototypes, even when produced with highly advanced tools, still contain bugs. Not because the tools are primitive, but because software manufacturing remains an activity of passage: from idea to language, from language to system, from system to the real world.

For decades, software production has advanced in this way:

write
→ test
→ fail
→ diagnose
→ correct
→ retest

This cycle is not an anomaly. It belongs to the general history of technology. No human society has ever produced complex artifacts perfectly on the first attempt. Tools, machines, buildings, industrial procedures, and organizations themselves were formed through trials, errors, corrections, adjustments, and successive stabilizations.

Software, despite its abstract appearance, does not escape this condition. It retains something artisanal. Every prototype is still, in part, a workshop piece: we assemble it, test it, listen to its cracks, identify its weak points, and then work it again.

SpQE Lab does not deny this reality. On the contrary, it makes it explicit.

It does not claim that every prototype must be born perfect. It organizes the trajectory through which a prototype becomes more reliable:

generation
→ validation
→ symptom detection
→ diagnosis
→ targeted repair
→ revalidation

This shift is precisely what matters. The bug ceases to be pure disorder. It becomes a readable event within a manufacturing chain. It can be localized, interpreted, corrected, and requalified.

One could say that the bug is the historical signature of a still-artisanal mode of software production. It testifies to an age in which manufacturing remains exploratory, hesitant, sometimes stammering, but already capable of regulating itself.

SpQE Lab may be standing at a turning point. It still belongs to this artisanal age, since it observes bugs, accepts them as symptoms, and corrects them through successive cycles. But it also prepares something else: a more controlled software manufacturing process, in which validation, diagnosis, and repair are integrated from the moment of generation.

The goal, then, is not simply to produce bug-free code by magic. The goal is to move software manufacturing toward a form of convergence that is more immediate, more observable, and more governed.

In this sense, SpQE Lab does not merely remove bugs. It documents the transformation from software craft toward controlled software manufacturing.

DCG2: A Miniature Anthropological Map

In this reading, a device such as DCG2 can be understood as far more than a technical tool. It functions as a condensed map of meaningful relationships between units of code. It does not claim to show everything. It isolates what matters for the stability of the system: who provides what, under which contract, and for which neighbors.

This economy of representation is precisely what we find in good anthropological maps. They do not record every gesture of every individual. They search for structure. They show lines of force, decisive relationships, passage points, and essential dependencies. In this sense, DCG2 almost belongs to structural anthropology applied to software.

It is not a total call graph. It is a capsule of relationships. And perhaps this is why it becomes so useful: it does not drown the observer in details, but helps him see the real organization.

A New Idea: From Occupational Physician to Code Physician

The connection then becomes almost inevitable. The occupational physician intervenes in human organizations to identify tensions, injuries, dysfunctions, and conditions of stability. In a certain sense, SpQE Lab applies a cousin gesture to software organization. It does not replace engineering. It expands it. It adds a layer of systemic observation.

This analogy is not merely a stylistic effect. It sheds light on the very origin of the project. A creator trained to observe companies as complex human environments could recognize, in code generated at scale, another type of complex environment, also crossed by rules, interactions, deviations, and crises. Where others might have seen a purely technical problem, he saw a field of observation, diagnosis, and regulation.

This may be one of ArchCode’s deepest singularities: it was not born only from a software ambition. It was born from a gaze. A gaze forged in the observation of human organizations, then transposed to organizations of code.

Conclusion

The idea of an anthropology of code may seem strange at first. Yet it becomes increasingly natural as software systems gain complexity, relational depth, and apparent autonomy. The time when code could be seen as a simple assembly of lines is receding. We are entering an age in which architectures must also be read as organized worlds.

In this context, SpQE Lab offers more than a method of generation. It offers a way of observing software as a system of relationships, constraints, and regulations. And perhaps this is where its strongest originality lies: understanding, from occupational medicine, that a complex system cannot be mastered only by building it, but by learning to listen to it, diagnose it, and read its symptoms.

In this sense, SpQE Lab does not treat code only as technique. It treats it as a form of organization. And it is precisely this shift in perspective that opens a new intellectual territory, at the frontier of engineering, anthropology, and the clinical study of complex systems.