Il existe un curieux écart dans le logiciel français, et plus largement européen. À une extrémité se trouvent les entreprises assez grandes pour transformer la pratique de l’ingénierie en infrastructure : Dassault Systèmes, Doctolib à son échelle actuelle, et leurs pairs mondiaux comme Amazon ou Microsoft, peuvent se payer des équipes plateforme dédiées, des outils internes, des comités d’architecture et des années de mémoire institutionnelle accumulée. À l’autre extrémité se trouvent les entreprises de garage et les petites structures qui ne prétendent avoir aucun cycle de vie de développement logiciel — elles déploient depuis un ordinateur portable parce que le produit tient dans une seule personne, que le client attend, et que l’alternative n’est pas un processus plus rigoureux mais l’absence de produit. Entre ces deux pôles se trouvent des milliers d’entreprises avec suffisamment de logiciel pour avoir besoin d’une discipline d’ingénierie, et pas assez de marge, d’attention ou de mou organisationnel pour en faire une priorité de premier plan. Ce milieu est là où s’écrit en réalité la majorité du logiciel, et c’est la partie de l’industrie dont la littérature de l’industrie elle-même parle le moins.

I. Ce n’est pas un défaut de savoir

Le milieu manquant n’est pas un milieu ignorant. Les pratiques ont un nom — SDLC, conception pilotée par le domaine, intégration continue, observabilité, modélisation des menaces, tests automatisés, réponse aux incidents, documentation, revue de code. Les livres existent. Les consultants savent expliquer le modèle de maturité en salle de réunion, et les ingénieurs peuvent décrire de mémoire les conséquences de sauter chaque étape, parce que la plupart les ont vécues eux-mêmes. Le problème n’a jamais été l’ignorance. Le processus arrive dans ces organisations comme une préoccupation de second ordre, subordonnée à ce que le marché sanctionne ce trimestre-là.

Cette distinction compte. Dire qu’une entreprise “n’a pas de culture d’ingénierie” fait passer l’échec pour de la négligence. C’est souvent plus proche du triage. Le commercial a besoin d’une fonctionnalité avant qu’un concurrent ne la sorte. Un client a trouvé un bug en production et menace de partir. Le conseil d’administration veut des preuves de croissance pour vendredi. Une migration a déjà glissé deux fois. Dans ces conditions, le processus n’est pas rejeté par principe — il est repoussé, et ce report se répète jusqu’à ce que l’exception devienne le mode de fonctionnement. Ward Cunningham a forgé l’expression “dette technique” à OOPSLA en 1992 comme une métaphore, pas comme une accusation : un emprunt contracté délibérément, avec l’intention de le rembourser. Ce que la métaphore omet, c’est que dans le milieu manquant, personne ne programme jamais le remboursement. Il y a toujours un emprunt plus urgent à contracter d’abord.

II. L’avantage d’échelle des géants

Au sommet du marché, le processus devient un atout concurrentiel parce que l’échelle crée la marge nécessaire pour le financer. Une entreprise qui sert des centaines de millions d’utilisateurs peut justifier une équipe entière dont le travail consiste à rendre les autres équipes plus rapides et plus sûres. Elle peut absorber la réécriture d’une plateforme, tenir un catalogue de services, exiger des revues de conception et traiter la fiabilité comme une fonctionnalité du produit, parce qu’une panne a un coût mondial mesurable. La machinerie interne d’Amazon — le mémo narratif de six pages qui remplace la présentation PowerPoint, le communiqué de presse “working backwards” rédigé avant la première ligne de code, l’équipe “deux pizzas” comme unité organisationnelle — est documentée avec assez de détails, notamment dans Working Backwards de deux de ses anciens dirigeants, qu’elle se lit moins comme une culture que comme une infrastructure dotée d’une ligne budgétaire.

Ce n’est pas une vertu supérieure. C’est une économie d’échelle. Le processus d’ingénierie a un coût fixe : quelqu’un doit le définir, l’enseigner, l’automatiser, le mesurer et le défendre contre la prochaine demande urgente. Réparti sur suffisamment de revenus et suffisamment d’équipes, cet investissement finit par paraître évident. Fred Brooks, décrivant ce qui dévore réellement le calendrier d’un grand projet logiciel dans Le mythe du mois-homme, soutenait que la charge de communication croît plus vite que les effectifs — et les géants ont répondu non pas en restant petits, mais en industrialisant cette charge elle-même, en dessinant l’organigramme sur mesure pour le logiciel, exactement à l’inverse de la loi de Conway, qui observe que les systèmes finissent par prendre la forme des organisations qui les construisent. À cette échelle, on peut se permettre de concevoir l’organisation exprès.

III. L’avantage du fondateur

Les plus petites entreprises échappent aux mêmes attentes pour la raison inverse. Un fondateur peut porter tout le système dans sa tête. La personne qui parle au client est celle qui modifie le code, déploie le service et remarque quand quelque chose casse. Il n’y a peut-être aucun SDLC formel, mais la boucle de rétroaction est courte et le modèle du domaine se transmet socialement plutôt que par écrit. Cet arrangement échoue dès que le système ou l’équipe grandit, mais avant ce point, la cérémonie économisée peut valoir plus que le risque futur qu’elle diffère.

L’entreprise de garage n’est pas forcément immature de fonctionner ainsi. Elle fait peut-être un échange rationnel — vitesse et survie maintenant contre maintenabilité plus tard. Le problème commence quand l’entreprise conserve son modèle opérationnel de startup après avoir acquis la complexité d’une institution plus grande. Une équipe de douze personnes ne peut plus partager chaque hypothèse. Un produit avec plusieurs intégrations ne peut plus se comprendre sûrement de mémoire. L’organisation a franchi le seuil où la coordination informelle cesse de passer à l’échelle, mais le marché ne lui a pas encore accordé le budget pour bâtir une alternative formelle.

IV. La taxe des priorités

C’est là que le milieu se retrouve piégé. Chaque pratique d’ingénierie entre en concurrence avec une priorité commerciale visible. Les tests ne ressemblent pas à du chiffre d’affaires. Le refactoring n’apparaît pas dans la démo. La documentation ne produit aucune capture d’écran pour le conseil d’administration. La modélisation du domaine est la plus difficile à défendre précisément quand le domaine change le plus vite. L’organisation voit le coût de retarder une fonctionnalité aujourd’hui et ne peut qu’estimer le coût d’affaiblir le système demain — et les estimations perdent face aux lignes budgétaires dans chaque réunion de budget jamais tenue.

Alors l’entreprise coupe les coins, livre d’abord, et promet d’imposer le processus plus tard. Parfois c’est la bonne décision — le logiciel n’est pas un pont, et chaque livraison ne mérite pas la même cérémonie. Mais le “plus tard” a l’habitude d’arriver accroché à une autre échéance. L’exception temporaire devient précédent, le précédent devient attente, et finalement on dit à l’équipe que le processus échoue alors qu’il n’a jamais eu le droit de faire partie de la définition du “terminé” du produit. Le résultat n’est pas le chaos au sens dramatique. C’est une lente taxe des priorités : chaque raccourci renchérit légèrement le prochain changement, chaque hypothèse non documentée rend une personne un peu plus indispensable, et chaque urgence laisse l’organisation un peu moins capable d’investir dans les conditions qui empêcheraient la prochaine. L’entreprise reste fonctionnelle, ce qui explique justement pourquoi la taxe est si difficile à voir. Elle se paie en options perdues, pas en échecs visibles.

V. Ce que “premier plan” voudrait vraiment dire

Faire du processus d’ingénierie une priorité de premier plan ne peut pas vouloir dire importer les rituels d’Amazon dans une entreprise de vingt ingénieurs — cela confond la forme visible de l’échelle avec la raison d’être de la pratique. La question est plus modeste et plus exigeante : quelles habitudes minimales préservent la capacité de l’organisation à comprendre, modifier et réparer son propre système à mesure qu’elle grandit ? Un test autour d’une règle critique pour le revenu peut compter plus qu’un objectif de couverture à cent pour cent. Un vocabulaire de domaine partagé, ce qu’Eric Evans appelait un langage ubiquitaire, peut compter plus qu’une architecture à la mode. Un déploiement réversible en cinq minutes peut compter plus qu’un train de mises en production élaboré que plus personne n’a le temps de faire rouler.

Le milieu manquant n’a pas besoin d’un processus maximal. Il a besoin d’un processus explicite — un accord délibéré sur les risques que l’entreprise accepte, les décisions qui doivent être consignées, et les raccourcis qui expirent au lieu de devenir permanents. La difficulté n’a jamais été de choisir les outils. C’est de donner à quelqu’un assez d’autorité et de temps pour défendre l’avenir face au présent, sans prétendre que le présent est irrationnel de demander à survivre.

Pour aller plus loin