ATAM 2025 - Le code est une Res Publica

Transcript

1. Le code est une Res Publica Partager le pouvoir ou le garder ?
2. Sponsors et partenaires 2025
3. Guillaume SAINT ETIENNE 44 years later ... 😳
4. pitch amélioré (et améliorable si besoin) "Une bataille pour le pouvoir" Pour vous, le code n'est surement qu'une suite d'instructions exécutées par une machine ou dans un cloud. Mais il est en réalité tellement plus que cela. Pouvons-nous même, nous faire une idée réelle de tout ce dont il est l'enjeu ? Le code est le vecteur de l'organisation des entreprises, jusqu'à ses idéaux. Ce n'est pas une technique, c'est un miroir. Et si nous osions regarder au travers, pour une fois ? À cause de la diversité à produire du code en entreprise, à cause de la multiplicité des formes d'organisations possibles, mais aussi des différents credo ou chapelles qu'ont créées les "faiseurs" de code; j'ai pu voir nombre de conflits, de résultats plus ou moins heureux, plus ou moins achevés. Une histoire avec des humains, des chef-fes, des technicien-nes, des testeur-euses, des PO, des SM,EM. CTO... et au final, si tout se passe bien, un ou des produits… Je remets tout cela en perspective avec les grandes Sociétés Humaines et l'organisation du Travail. Et je répondrai à ces 6 questions : Qu’est-ce que le code ? Qu’est-ce que le pouvoir de faire du code ? Y a-t-il une société secrète dans votre compagnie ? Quels sont les enjeux du pouvoir ? Quels sont les formes du pouvoir ? Quelles sont les techniques du pouvoir ?
5. Pourquoi ce sujet ?
8. Aucune ligne de code ne sera maltraitée (ni montrée) dans cette présentation
9. l’IT et vous
10. Aux sources du CODE
11. de l’organisation de la société • Être régi par des lois et non par des hommes 👉 l’idéal de la Loi 📖 • L’objectivité de la Loi La Gouvernance Par Les Nombres, Alain Supiot , p . 30 Alain Supiot - Le règne de la loi, les avatars d'un idéal
12. Les lois de la nature la Loi des Hommes
13. Le rêve de l’harmonie par le calcul Fascination des nombres La mécanique céleste Mise en équation du vivant
14. L’ère de la machine in LGPLN, p.36
15. La machine à gouverner https://mana.net/12861/
16. Loi, Justice & économie >Law & Economics (1960s): emprunte aux principes de l’ économie pour rendre la Justice >Analyse coût - avantage >Remplacer le jugement par le calcul
17. 1999 “Code is Law” https://www.harvardmagazine.com/2000/01/ code-is-law-html
18. Le logiciel dévore le monde En 2011, Marc Andreessen, père du légendaire navigateur internet Mosaic et co-fondateur de l'illustre Netscape, fait le buzz avec la sortie de son article, devenu très célèbre, dans le Wall Street Journal : " Pourquoi le logiciel dévore le monde ".
19. Cyberspace is everywhere “Some things never change about governing the Web. Most prominent is its innate ability to resist governance in almost any form.” Tom Steinert-Threlkeld, “Of Governance and Technology,” Inter@ctive WeekOnline, October 2,1998 https://www.lemonde.fr/idees/article/2025/04/29/les-algorithmes-contre-la-societe -contester-la-soumission-au-cynisme-des-calculs_6601481_3232.html
20. Le code construit le produit qui construit la société “la politique, aujourd’hui, se trouve aussi dans les algorithmes” Nadja Gaudillière-Jami, architecte.
21. Code is ours... and remains “Code is never found; it is only ever made, and only ever made by us.” As Mark Stefik puts it,“Different versions of [cyberspace/code] support different kinds of dreams. We choose, wisely or not.” “You build things here, and they survive your leaving” https://archive.nytimes.com/www.nytimes.com/books/first/l/lessig-code.html
22. Loi de Conway en 1968 : « Les systèmes (code) conçus dans une organisation reflètent inévitablement les structures de communication de cette organisation ». https://mixitconf.org/2023/loi-de-conway -lorsque-votre-conception-produit-se-fac he-avec-votre-organisation
23. “Notre (code), comme toute œuvre humaine, donne à voir les images qui ont présidé à sa conception” citation détournée d’Alain Supiot, “La Gouvernance par les nombres” (introduction, Fayard, 2015)
24. Si le code est un pouvoir Alors écrire du code est un super pouvoir
25. Cela suppose de coder nos valeurs dans les systèmes (garde-fous, traçabilité, réversibilité), de procéder à des essais dans le maximum de situation (temps, météo, nombres différents d’acteurs, etc.), d’enseigner ce que l’on pourrait appeler « l’humilité algorithmique », du sergent au général.
26. Du pouvoir de faire du code. Qui écrit le code ?
29. code et politique
30. politics everywhere Politics is just how humans coordinate in groups. It’s the invisible network of relationships, influence, and informal power that exists in every organization. https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/
31. politics in building a software • Building relationships before you need them. • Understanding the real incentives. • Managing up effectively. • Creating win-win situations. • Being visible. https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/
32. politics in tech Think about the last time a terrible technical decision got pushed through at your company. https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/
33. De la (vraie) nature du code
34. Technique ? Art ? Esthétique ? Vérité ? “This is only a foretaste of what is to come, and only the shadow of what is going to be. “
35. Technique ? Art ? Esthétique ? Vérité ? https://hackersandslackers.com/a-brief-history-of-pandas/ APL: A Programming Language
36. Xavier Leroy: Le logiciel, entre l’esprit et la matière https://www.lemonde.fr/blog/binaire/2018/11/12/a-la-recherche-du-logiciel-parfait/ Le logiciel est modelable (software) mais est exécuté dans du dur (hardware). Revers de cette flexibilité, le logiciel est aussi extrêmement vulnérable aux erreurs de programmation.
37. Le code est cette formalisation commune qui permet la réalisation d’un produit ou service.
38. Besoin Prod
39. Besoin Code Prod Specs CI CD
41. Bring the pain forward According to Neal Ford, continuous delivery adopts "Bring the pain forward," tackling tough tasks early, fostering automation and swift issue detection. [3]
42. Besoin Code MEP Dev Ops
43. Besoin Code MEP Dev Ops
44. Besoin Code Prod Dev Ops bugs + de features
45. Besoin Code Prod O ps bugs encore + de features Dev
46. Besoin Code Prod O ps + bugs encore + de features Dev
47. 🚨 Code 🚨 reviews bugs Besoin MEP
48. Le code est un champ de bataille le logiciel est la pièce logique, structurée qui doit (sur)vivre dans un monde chaotique: celui de l'entreprise, du domaine métier.
49. organisons (du code à la prod)
50. Pragmatisme Le code va devoir subir une somme de tensions qui vont conduire à l’émergence de normes et consensus au sein de l’appareil sociétal qui le produit : • => Entreprise • => Projet Open Source • => Bande de potes • ... • chacun ayant son propre système de référence
51. politique du code
52. La séparation de l’esprit et de la matière Alors que depuis l'aube de l’humanité, la pensée et main était inséparables, depuis le 19e, la machine sociale tend à séparer les 2. Entre le savoir et le faire, le divorce apparait au 20e siècle, prononcé par le corps social qui justifie cette division. 2 facteurs poussent dans ce sens : 1. la puissance des sciences pures (l’esprit peut imaginer l’intouchable : Einstein) 2. l’économie (rendement) du matériel (industrialisation, travail à la chaine) https://www.radiofrance.fr/franceinter/podcasts/l-heure-bleue/anti-burn-out-daniele-linhart-3345411
53. Le contrôle de l’ouvrage Code !
54. Code !
55. Une société secrète dans votre compagnie “le groupe”
57. Un peu de sociologie
58. De la sociologie dans le code Pair Programming Tour d’ivoire des architectes Mob Programming Superman Framework (ex. SAP, Joomla ... ) Syndrome du 󰭉 génie qui va tout vous expliquer (si il a le temps)
60. pour faire autorité
61. pour faire autorité dans le code The fundamental misunderstanding in Team Topologies
63. pour faire autorité dans le code
64. pour faire autorité dans le code
66. pour faire autorité dans le code
67. un mot sur les revues de code https://www.thesecretdeveloper.com/blog/the-battleground-of-the-software-developers-ego
68. Politique de l’organisation
69. Travailler à plusieurs Je vous guide !
70. Bicamérisme La "chambre basse" : les PO ou PM qui écrivent les specs, proches des besoins sur le terrain, réactifs aux besoins immédiats. La "chambre haute" : les architectes, CTO, qui définissent les grandes orientations, avec une vision technique et plus de recul (?). Et les développeurs ? de simples fonctionnaires qui écrivent le code à la demande ?
73. Complexité accidentelle ou conséquentielle ?
74. Complexité systémique et culturelle ❖ l’architecte répond aux injonctions ➢ techniques ➢ sociales ❖ le logiciel produit reprend les schémas sociaux intrinsèques de l’entreprise
75. Paralléliser le travail
76. Principe du Fordisme
77. t
85. Résolution sociale
86. Résolution technique (code is the law)
87. Find the right strategy https://dev.to/juniourrau/6-types-of-git-branching-strategy-g54
88. prendre les choses en mains
89. réduire la couche bureaucratique du besoin à la réalisation pour l’utilisateur besoin code ✈ 🌾 prod PO/PM techs
90. réduire la couche bureaucratique besoin code ✈ 🌾 prod
91. le code a changé
92. Le code a ENCORE changé
93. réduire la couche bureaucratique des besoins ... incluant: • normes • sécurité • cohésion technique • cohésion sociale besoin code ✈ 🌾 prod
94. réduire la couche bureaucratique . besoin code ✈ prod Quid de • normes ? • sécurité ? • cohésion ?
95. réduire la couche bureaucratique liberté ? régulation ? besoin code prod
96. Seront nous toujours libres ? 2 problèmes Nous serons dégagés de toute responsabilité environnementale (tous types d’environnement : technique, mais aussi impact sur la planète) que peut nous faire sentir l’expérience directe. (in: Éloge du carburateur)
97. Conversation ≠ Code
98. Experiences Agentiques “spec is the law”
101. Partager le pouvoir Partager le code code => connaissances <= pouvoir
102. bicamérisme interne (niveau entreprise) Les freins dans le modèle actuel : • Monopole de décision : les PO/PM + product managers décident seuls • La dette technique: peu prise en compte, tends à exploser, rend le travail des devs+ops difficile • Conflits d'intérêts structurels : optimiser pour l'engagement ≠ optimiser pour le bien-être et la faisabilité Solutions émergentes : • Comités d'éthique IA chez Google, Microsoft (et leurs échecs instructifs) • Le "Tech Won't Build It" - quand les développeurs refusent certains projets • Les IRB (Institutional Review Boards) dans la recherche - modèle transposable ?
103. bicamérisme sociétal (niveau macro) Chambre basse = Le marché et l'innovation • Entreprises tech qui innovent rapidement • Développeurs qui expérimentent • Logique de l'efficacité et de la croissance Chambre haute = Régulation et intérêt général • Régulateurs (DSA, RGPD en Europe) • Représentation citoyenne dans les décisions tech • Logique du temps long et de la délibération
104. Tensions et apories du modèle La question de la compétence : • Dans une république, les citoyens peuvent comprendre les lois • Peut-on comprendre un algorithme de deep learning ? • Le bicamérisme fonctionne quand les deux chambres parlent le même langage La capture régulatoire : • Les experts techniques finissent souvent dans les deux chambres • Le revolving door entre GAFAM et régulateurs • Comment éviter que la "chambre haute" soit colonisée par la "chambre basse" ?
105. Solution : le Domain Driven Design Le DOMAINE (métier) est la connaissance Disséminer le DOMAINE jusque dans le CODE par le Language Ubiquitaire Écrire du code que tout le monde peut comprendre (Fluent) Masquer la “technicité” tout en reconnaissant qu’elle est cruciale
106. https://github.com/ddd-crew/
107. La dette technique comme dette souveraine Parallèle avec la dette publique : • Les gouvernements empruntent pour satisfaire des besoins immédiats, repoussant le coût aux générations futures • Les organisations tech accumulent de la dette technique pour livrer rapidement, repoussant le coût aux équipes futures • Dans les deux cas : temporalité politique court-termiste vs. conséquences long terme 📐 Dette technique = Coût Marginal de la prochaine Feature
108. la dette n’est pas bankable Pourquoi on ne la voit pas : • Invisibilité : La dette technique ne se voit pas dans un dashboard business • Incommensurabilité : Comment traduire "notre base de données est mal architecturée" en impact business ? • Décalage temporel : Les décisions d'aujourd'hui créent des coûts dans 2-3 ans, après que les décideurs soient partis ou promus • Asymétrie informationnelle : dépendent des développeurs pour comprendre l'état réel du système Pourquoi ils l'ignorent consciemment : • Incitations perverses : les bonus sont sur la croissance trimestrielle, pas la maintenabilité • "Technical debt is a problem for future-me" (et future-me sera ailleurs) • Pression des investisseurs/actionnaires pour la croissance rapide • Le refactoring ne se "vend" pas : pas de feature visible
109. Le bicamérisme face à la dette technique : échec systémique Problème 1 : Horizon temporel inadapté • (operationel) : pense en sprints (2 semaines) • (business) : pense en quarters (3 mois) ou en levées de fonds • Dette technique : se matérialise en années. Problème 2 : Absence de représentation du futur • Dans une démocratie, les générations futures ne votent pas → sous-investissement dans l'environnement, les retraites, etc. • Dans une organisation tech, "l'équipe de 2027" n'est pas à la table aujourd'hui • Ceux qui paieront la dette ne sont pas ceux qui décident de la contracter
110. Problème 3 : L'illusion de la liquidité • Une entreprise peut toujours "se permettre" encore un peu de dette technique ("on le fera plus tard") • Comme une carte de crédit : la limite n'est pas visible jusqu'au refus • Pas de "notation" de la dette technique comme pour les obligations souveraines Problème 4 : La tragédie des communs inversés • La qualité du code est un bien commun de l'organisation • Chaque équipe a intérêt à prendre des raccourcis (bénéfice local) • Tout le monde subit les conséquences (coût global) • Aucune des deux chambres n'arbitre vraiment Le bicamérisme face à la dette technique : échec systémique
111. des dimensions politiques de la dette Le temps comme dimension politique du code : • Le code n'existe pas seulement dans l'espace (qui y a accès, qui le contrôle) • Mais aussi dans le temps (qui paie pour sa maintenance) • La dette technique est une violence différée exercée sur les futurs développeurs et utilisateurs L'irresponsabilité structurelle : • Dans le droit classique : principe de responsabilité (tu paies pour tes actes) • Dans le code : irresponsabilité temporelle (tu crées la dette, d'autres la rembourseront) • Les incitations individuelles sont découplées des conséquences collectives Le code comme ruine accélérée : • Une cathédrale met des siècles à se dégrader • Un code mal écrit devient "legacy" en 2-3 ans
112. Propositions : Une troisième chambre ? La chambre de la soutenabilité technique Une institution qui représenterait explicitement le long terme technique : Composition : • Architectes seniors (pas impliqués dans la delivery quotidienne) • SRE (Site Reliability Engineers) - ceux qui gèrent les conséquences de la dette • Développeurs "émérites" avec mémoire institutionnelle • Éventuellement : anciens développeurs devenus CTO ailleurs (regard externe)
113. Autres mécanismes institutionnels 1. Le "budget carbone technique" • Chaque équipe a un quota de dette qu'elle peut créer • Comme les quotas carbone : création d'un marché interne • Force à arbitrer : "cette feature vaut-elle vraiment 10 points de dette ?" 2. Les "technical debt amnesty days" • X jours par an où toute l'organisation arrête les features • Concept emprunté aux amnisties fiscales • Reconnaissance institutionnelle que la dette est normale mais doit être gérée 3. Le "future team advocate" • Quelqu'un dont le job est littéralement de représenter l'équipe de 2027 • Dans chaque réunion de planning : "Que penseront nos successeurs ?" • Inspiré des "ombudsman" scandinaves ou des "défenseurs des générations futures"
114. Le cas particulier de l'open source L'open source révèle une dimension supplémentaire fascinante : Dette technique socialisée : • Les mainteneurs (souvent bénévoles) héritent d'une dette créée par l'usage commercial • Heartbleed (bug OpenSSL) : infrastructures critiques mondiales reposaient sur un projet maintenu par quasi-personne • Qui "rembourse" la dette d'un projet open source dont dépendent des milliers d'entreprises ? Tentatives de solution : • Tidelift, Open Collective : financement des mainteneurs • Mais fondamentalement : externalisation de la dette technique sur le commun numérique