Peut-on déployer le réel autrement ?

Introduction — pourquoi écrire ce texte aujourd’hui

Je n’ai pas pour habitude d’écrire sur mon métier ou mes convictions. Mais après quinze années plongé dans le développement logiciel, j’éprouve le besoin de prendre du recul et de partager certaines réflexions. Ce n’est pas un manifeste technique ni un récit autobiographique, mais une tentative de mettre en ordre des idées forgées au contact du code et des systèmes. Aujourd’hui, en tant que CTO après avoir longtemps été ingénieur logiciel, je ressens l’urgence intellectuelle de clarifier ce que ces années de pratique m’ont appris sur l’action, la technique et la cohérence du monde.

Au fil du temps, j’ai vu des langages et des frameworks naître et mourir, des projets réussir et d’autres échouer. Dans ce tumulte permanent, certaines constantes se dégagent. Écrire ce texte maintenant, c’est saisir l’occasion d’isoler ces constantes et de les examiner à la lumière d’une expérience vécue. C’est aussi une manière de transmettre une vision : celle d’un monde où le code et la réalité s’entrelacent, et où la lucidité technique peut éclairer au-delà de l’écran.

Le monde technologique a énormément évolué depuis mes débuts. Les outils, les langages et les méthodes d’hier ne sont plus ceux d’aujourd’hui : ce qui était marginal est devenu courant (le cloud, l’automatisation, l’open source), tandis que certaines pratiques autrefois centrales ont disparu ou se sont transfigurées. Cependant, avec le recul, je constate que certaines leçons fondamentales restent valables par-delà les tendances et les vagues d’innovations successives. C’est précisément ces leçons pérennes que je souhaite mettre en lumière ici.

En outre, mon passage de développeur, à celui du rôle d'ingénieur logiciel puis de tech lead et finalement de CTO a servi de catalyseur à cette remise en perspective. Changer d’échelle de responsabilités, passer de l’écriture du code à l’orchestration d’une vision technique, m’a contraint à clarifier mes principes directeurs. Il m’a semblé qu’il était temps d’en poser les fondations par écrit, avant de poursuivre le chemin avec ce regard affiné.

15 ans de code : apprendre à agir dans le local, comprendre par l’itération, évoluer par la friction

Après toutes ces années, la première leçon qui s’impose est celle de la modestie du champ d’action. En développement logiciel, on apprend à agir dans le local : c’est-à-dire à traiter les problèmes à l’échelle où ils se posent réellement. Face à la complexité d’un système entier, il est tentant de vouloir tout embrasser d’un coup, mais cela mène souvent à l’échec. J’ai appris qu’il faut savoir se concentrer sur une fonction, un module, une interaction à la fois. Régler un détail concret, ici et maintenant, peut débloquer une situation globale sans qu’il soit nécessaire de tout repenser d’emblée. Le code nous enseigne la puissance de l’effet local : une correction précise dans une petite partie du système peut rétablir l’équilibre de l’ensemble.

Comprendre par l’itération est la seconde leçon majeure. Ni le code ni les idées ne naissent parfaits du premier coup. Il m’a fallu réécrire, refactorer, tester et recommencer d’innombrables fois pour réellement saisir ce que je faisais. Cette approche itérative n’est pas un aveu d’incompétence, c’est au contraire une méthode de compréhension progressive. Chaque itération révèle un aspect nouveau du problème ou de la solution. En améliorant un algorithme version après version, on découvre les véritables contraintes du problème et la réelle nature de la solution. Au fil des cycles, l’objectif initial gagne en clarté, comme une image qui se précise à chaque passage. C’est d’ailleurs l’essence des méthodes Agiles : apprendre en construisant par ajustements successifs, plutôt que de tout figer d’emblée.

Enfin, on évolue par la friction. Les avancées les plus significatives que j’ai connues sont nées de résistances, d’obstacles ou d’erreurs. Une application qui plante en production, un utilisateur qui détourne un outil de son usage prévu, une équipe qui débat ardemment d’une architecture : ces frictions sont douloureuses sur le moment, mais précieuses sur le long terme. Chaque bug critique rencontré m’a forcé à améliorer mes pratiques de conception ou de test. Chaque désaccord technique m’a poussé à mieux articuler mes arguments et à affiner ma vision. La friction, qu’elle vienne du réel ou des interactions humaines, agit comme un aiguillon qui nous oblige à sortir de notre zone de confort technique. C’est par ces heurts que le développeur mûrit et que le logiciel se consolide.

En somme, se cantonner au local, itérer patiemment et accepter la friction comme moteur de progrès forment une philosophie pragmatique du développeur. Ces principes guident mes choix quotidiens : ils m’empêchent de succomber aux mirages d’une refonte totale quand un ajustement ciblé suffit, ils m’encouragent à prototyper vite plutôt qu’à théoriser indéfiniment, et ils me rappellent qu’une difficulté rencontrée est souvent le prélude à une amélioration future. En d’autres termes, le code m’a appris à avancer pas à pas, sans crainte de me tromper, car chaque pas, même faux, fait partie du chemin. À force d’appliquer ces principes projet après projet, j’ai vu se profiler une compréhension d’un ordre supérieur : celle du comportement global des systèmes. Une sorte de « vie » du logiciel est apparue à mes yeux, au-delà des lignes de code prises isolément.

La révélation systémique : tout système est vivant, chaque ligne de code est un état dans un cycle plus vaste

Travailler assez longtemps sur un même projet ou un même produit apporte une forme de révélation : on voit le logiciel changer, s’adapter, parfois dégénérer et renaître. Un système logiciel n’est pas un artefact figé, c’est un organisme en évolution constante. Chaque nouvelle fonctionnalité ajoutée, chaque correctif apporté, modifie l’état du système tout entier. J’ai pu observer qu’une base de code, au fil des années, subit des métamorphoses comparables à celles d’un être vivant : elle croît, se complexifie, s’assainit ou s’alourdit, selon les pressions qu’elle subit et les soins qu’on lui prodigue. La plupart des fonctions que j’ai écrites il y a dix ans n’existent plus dans le code actuel, refondues, déplacées ou supprimées, mais le produit, lui, est toujours là, plus robuste et plus riche qu’à l’origine.

Dans cette perspective, chaque ligne de code est un état, un instantané dans le cycle plus vaste de vie du programme. La ligne que j’écris aujourd’hui n’est peut-être qu’une étape transitoire : elle pourra être refondue lors d’une prochaine version, ou supprimée quand le système n’en aura plus besoin. Au moment où je la pose, cette ligne reflète l’état actuel de notre compréhension du problème et de la solution. Mais cette compréhension elle-même évolue : de nouvelles contraintes émergeront, l’environnement technique changera, les besoins des utilisateurs se déplaceront. Alors le code changera à son tour. Un programme vit aussi par ses utilisateurs : leurs retours, voire leurs usages inattendus, forcent son adaptation, comme un organisme qui doit s’ajuster à son écosystème. Ainsi, le logiciel traverse un cycle perpétuel de création et de transformation, où l’immuable n’existe pas vraiment.

Cette révélation systémique a des conséquences sur la façon d’aborder le développement. Elle incite à l’humilité et à la vigilance : chaque décision technique, même mineure, s’inscrit dans un cadre plus large qui la dépasse. Le développeur n’est pas un simple écrivain de lignes de code isolées, il est le gardien temporaire d’un écosystème logiciel en mouvement. Comprendre qu’un système est « vivant », c’est accepter qu’il faille l’accompagner plutôt que le contrôler absolument. Cela signifie concevoir des architectures capables d’évoluer, mettre en place des tests pour surveiller la santé du système, et toujours garder à l’esprit que le code interagit avec un monde plus vaste que lui.

Il n’y a pas que le code : tout système complexe, une organisation, un projet d’entreprise, obéit lui aussi à un cycle de vie. J’ai constaté que les équipes et les processus évoluent selon des dynamiques comparables : phases de croissance, crises de réorganisation, adaptations successives. La vision systémique née du développement logiciel devient alors un atout pour appréhender ces réalités-là également. Autrement dit, le regard formé par le code s’avère utile pour décrypter bien d’autres complexités que le seul logiciel.

Récurrence et déterminisme : voir le monde comme un moteur à états, où tout finit par rejouer

À force de penser en termes de systèmes et de cycles, on en vient à percevoir des motifs de récurrence bien au-delà du code. J’ai pris l’habitude d’analyser les situations, techniques ou même humaines, comme des moteurs à états : un ensemble d’états possibles, avec des transitions régies par des conditions. Dans cette optique, le hasard pur s’estompe et fait place à l’idée d’un enchaînement presque mécanique des événements. Chaque cause entraîne un effet, et lorsque les conditions se répètent, l’effet finit lui aussi par se répéter.

En observant le monde professionnel et technologique, j’ai constaté que tout finit par rejouer sous une forme ou sous une autre. Les mêmes types de bogues ressurgissent lorsqu’on développe des applications similaires, même si l’on change de langage ou de plateforme. Les débats techniques que je croyais tranchés reviennent cycliquement à mesure que de nouvelles générations de développeurs redécouvrent d’anciennes questions (synchronisation vs asynchronisme, monolithe vs microservices, centralisation vs distribution…). Il semble que, tel un cycle naturel, les idées et les problèmes évoluent en boucles plutôt qu’en ligne droite. On assiste souvent à un mouvement de balancier : après l’engouement pour la centralisation vient le retour au distribué, puis l’histoire se répète sous un autre nom. Ainsi, la nouveauté absolue est rare ; ce que l’on prend pour une révolution est fréquemment une itération sur un thème connu. Avec le temps, j’ai appris à ne plus m’étonner de voir l’industrie « redécouvrir » des idées du passé : ce phénomène fait partie du cycle normal de maturation collective. Plutôt que d’y voir une incohérence, j’y reconnais le rythme régulier par lequel notre milieu intègre et affine les leçons du passé.

Cette vision déterministe du monde, héritée de la logique logicielle, apporte une forme de lucidité structurante. Elle suggère que rien n’arrive sans raison discernable, que toute situation est l’aboutissement d’un ensemble de conditions préalables. Si l’on connaît suffisamment l’état d’un système à un instant T, on peut anticiper en partie son état futur, du moins dans les limites de notre compréhension. Bien sûr, le monde réel reste plus imprévisible qu’un programme : la complexité y est infiniment plus grande et notre connaissance toujours partielle. Néanmoins, raisonner ainsi m’a aidé à démystifier bien des phénomènes : au lieu d’y voir la fatalité ou la magie, j’y vois des chaînes de causes et d’effets, parfois longues et intriquées, mais rationnelles.

Le paradoxe de l’action lucide : agir en sachant que tout est déjà enchevêtré, prédisposé, structurel

Une fois qu’on a compris à quel point les événements s’inscrivent dans des structures préexistantes, une question se pose : comment agir en connaissance de cause ?

Cette lucidité pourrait conduire au fatalisme.

Si tout est enchevêtré dans des chaînes de causes complexes, si tout semble en grande partie prédisposé par la structure des systèmes, alors nos marges de manœuvre individuelles paraissent infimes. Le risque serait de se dire que, puisque « tout est écrit d’avance » ou presque, nos efforts sont vains. C’est là le paradoxe auquel je me suis trouvé confronté : savoir ce qu’il en est des déterminismes du monde, tout en devant continuer à prendre des décisions et à innover.

Ma réponse à ce dilemme a été d’adopter une action lucide plutôt qu’une résignation. Agir lucidement, c’est agir avec la pleine conscience des contraintes et des interdépendances, sans les ignorer mais sans s’y soumettre passivement non plus. Autrement dit, il s’agit de jouer avec les règles du système plutôt que de prétendre les abolir. Dans le développement logiciel, cela signifie par exemple anticiper les effets de bord d’une modification, tenir compte des dépendances existantes, et ne pas espérer une “solution miracle” isolée de tout contexte. On intervient en sachant que chaque changement s’insère dans un réseau de causes et conséquences ; cette connaissance nous permet de cibler les leviers les plus efficaces plutôt que de frapper dans le vide. Il s’agit de conserver l’initiative sans se bercer de l’illusion d’un contrôle absolu.

Il y a une forme de sérénité à tirer de cette approche. Au lieu de s’angoisser de ne pas tout contrôler, on se concentre sur ce qui peut l’être. On accepte que chaque action s’inscrive dans un cadre plus large qui lui donne du sens. Cela n’empêche pas l’ambition ou l’effort, au contraire : savoir que tout est structurel incite à travailler sur la structure elle-même, quand c’est possible, ou du moins à en tenir compte. En tant que CTO, cette attitude m’amène à décider en gardant à l’esprit les limitations systémiques, mais aussi les opportunités qu’offrent les cycles et les régularités du système. C’est une façon d’avancer avec lucidité sans perdre le désir d’améliorer les choses. Cette lucidité n’a rien d’un pessimisme stérile : c’est un réalisme actif que je m’attache à transmettre à mes équipes, afin qu’elles gardent l’enthousiasme tout en gagnant en précision dans leurs efforts.

L’architecte du réel : pourquoi le rôle du CTO dépasse la technique, et touche à la cohérence du monde

Arrivé à ce stade, une conviction s’est imposée à moi.

le rôle de CTO ne se limite pas à aligner des serveurs et à écrire du code élégant. Il s’agit en réalité d’être un architecte du réel, c’est-à-dire quelqu’un qui façonne une partie du monde concret à travers les systèmes technologiques.

Chaque décision que je prends en matière de technologie a des répercussions bien au-delà du département IT : elle influence la façon dont les collaborateurs travaillent, dont les clients interagissent avec l’entreprise, voire la manière dont certaines tâches s’intègrent dans le quotidien de chacun. En ce sens, le CTO touche directement à la cohérence du monde professionnel qui l’entoure. Cela implique de dialoguer avec tous les acteurs de l’entreprise, des équipes métiers jusqu’à la direction générale, pour que les solutions techniques s’alignent sur la vision stratégique et les réalités du terrain. Concrètement, il m’arrive d’endosser un rôle de médiateur : expliquer aux développeurs les contraintes opérationnelles pour orienter leurs implémentations, ou inversement traduire aux équipes métier les implications d’un choix technique. C’est par ce travail d’interprète entre le langage du business et celui de l’ingénieur que l’on préserve l’alignement du système avec le réel.

Pourquoi parler de cohérence ?

Parce qu’un système technique n’a de valeur que s’il s’articule harmonieusement avec la réalité qu’il vise à outiller. Un logiciel, aussi sophistiqué soit-il, échoue s’il crée de l’incohérence. Par exemple en imposant aux utilisateurs des processus illogiques par rapport à leur métier, ou en générant des données que personne ne peut relier aux faits. Le CTO doit donc veiller à ce que la cohérence soit maintenue entre le monde du code et le monde tout court. Cela signifie comprendre finement le domaine fonctionnel (finance, santé, industrie…), traduire ses exigences en solutions techniques, et réciproquement adapter la technique aux contraintes du réel. En orchestrant ce va-et-vient entre deux univers, le CTO s’érige en garant de la continuité logique entre l’intention humaine et la réalisation logicielle.

Dépasser la technique, pour un CTO, c’est aussi embrasser des considérations éthiques, organisationnelles et stratégiques. L’architecte du réel doit penser aux conséquences à long terme de ses choix : non seulement sur la performance du système, mais sur les personnes qui l’utilisent et sur l’environnement dans lequel il s’insère. Par exemple, choisir d’automatiser un processus va redéfinir le travail de plusieurs individus ; opter pour telle architecture cloud a un impact sur la résilience de l’entreprise face aux aléas. Il lui faut également naviguer entre les attentes parfois divergentes : celles des dirigeants qui voient la technologie comme un levier stratégique, celles des équipes techniques pour qui elle est une passion et une expertise, et celles des utilisateurs finaux qui y cherchent un outil efficace et simple. Chaque choix technologique contribue à façonner un pan de la réalité de l’entreprise, voire de la société, à l’ère du numérique. Conscient de cela, je vois mon rôle comme celui d’un architecte de cohérence : s’assurer que les briques technologiques s’assemblent en un édifice stable, utile et aligné avec les besoins réels et les valeurs portées par l’organisation.

Conclusion — écrire pour faire apparaître la structure

Si j’ai choisi de m’exprimer par l’écriture, c’est que ce médium oblige à la clarté et à l’organisation de la pensée. Tout comme le code est une mise en forme explicite d’une logique pour la rendre exécutable, l’écriture est une mise en forme d’une réflexion pour la rendre partageable. En posant ces mots, j’ai cherché à faire apparaître la structure sous-jacente à quinze ans d’expérience : les liens de cause à effet, les cycles récurrents, les principes d’action qui ont émergé. Cet exercice a fait ressortir un ordre là où, peut-être, régnait initialement une intuition diffuse.

Écrire ces lignes m’a procuré le même sentiment que refactorer un ancien programme pour en révéler l’architecture fondamentale. On ôte le superflu, on éclaire les dépendances, on distingue les modules et leur interaction. De la sorte, le calme intérieur s’installe peu à peu, non pas parce que tout serait simple, mais parce que tout devient lisible. La complexité demeure, mais on en aperçoit la logique interne, et cela suffit à donner un sens d’ordre. Si ce texte parvient à communiquer ne serait-ce qu’une fraction de ce sentiment de cohérence et de lucidité, alors il aura atteint son but.

Après quinze ans de développement logiciel, ma vision du métier et du monde s’est construite brique par brique, au gré des projets et des questionnements. Cette tribune personnelle en est la synthèse temporaire, figée à un instant T de ma propre évolution. Elle témoigne d’une conviction : en exposant clairement les structures qui nous traversent, nous pouvons agir avec plus de conscience, de précision et de sérénité.

En définitive, ce regard lucide et systémique ne profite pas qu’au CTO : c’est un atout précieux pour tout acteur de la technologie. À l’heure où la complexité des systèmes ne fait que grandir, la capacité à discerner un ordre caché devient une force ; la cohérence que nous apportons, si modeste soit-elle, fait toute la différence.

Cordialement vôtre,
Loïc Mancino