Un logiciel construit pour impressionner ceux qui l’écrivent plutôt que pour servir ceux qui le possèdent se repère à un indice simple : le nombre de technologies employées. Un système qui compte quatre bases de données, deux systèmes de files d’attente et un framework sorti au printemps dernier n’a pas été architecturé, il a été collectionné. Et le collectionneur paie rarement la facture de maintenance.
Le vrai coût de la technologie séduisante
Une technologie nouvelle se paie trois fois. D’abord en imprévus qu’on ne sait même pas nommer : les modes de défaillance dont aucun blog n’a encore parlé, que vous découvrirez à 2 h du matin, en production. Ensuite au recrutement : chaque choix exotique rétrécit le vivier des personnes capables de maintenir le système et fait monter leur prix. Enfin en longévité : le framework séduisant de cette année a une chance sur deux d’avoir été abandonné dans cinq ans. Les outils éprouvés, eux, ont déjà survécu à leurs extinctions.
Les trois factures se renforcent l’une l’autre. La base de données exotique tombe en panne d’une façon que personne n’a documentée, ce qui resterait surmontable ; sauf que le seul ingénieur qui la comprenait est parti au printemps, et que le recrutement de son remplaçant en est à son quatrième mois, le vivier sur cette compétence précise relevant de l’erreur d’arrondi. Pendant ce temps, le framework dont elle dépend annonce sa « nouvelle direction passionnante », formule d’éditeur qui signifie la réécriture de tout ce que vous aviez bâti sur l’ancienne. Ce n’étaient pas trois risques distincts. C’était un seul risque, acheté trois fois.
Ces coûts arrivent après le départ de l’agence. C’est précisément ce qui rend les agences structurellement sensibles au charme de la nouveauté : le bénéfice pour le CV leur revient, la facture de maintenance vous revient. Aligner ces intérêts relève de la rédaction du contrat autant que de l’ingénierie, et c’est une des raisons pour lesquelles nous garantissons notre travail et proposons d’exploiter ce que nous construisons.
La mécanique de l’accumulation
Personne ne décide un matin de construire un système impossible à maintenir : il s’accumule par des décisions individuellement défendables. Un ingénieur veut une technologie sur son CV, et le projet est le seul endroit où l’obtenir. Une conférence fait passer une architecture conçue pour mille ingénieurs pour une bonne pratique dans une équipe de six. Un schéma en microservices a l’air plus sérieux qu’un monolithe assumé. Chaque décision ajoute une pièce mobile, et les pièces mobiles se multiplient au lieu de s’additionner : deux bases de données ne coûtent pas deux fois une base de données, elles coûtent la seconde base plus la synchronisation entre les deux, indéfiniment.
La parade tient en une règle ennuyeuse, appliquée au moment de la revue : toute technologie qui sort de la stack par défaut doit justifier son entrée par une exigence mesurable que le choix par défaut ne satisfait pas. « C’est plus scalable » ne compte pas sans un chiffre. « On en aura peut-être besoin plus tard » est une raison de l’ajouter plus tard. La charge de la preuve pèse sur la nouveauté, jamais sur le choix ennuyeux : un seul des deux peut montrer un historique.
L’innovation est un budget. Dépensez-le sur le produit, là où vos clients le voient, plutôt que sur l’infrastructure, où seuls vos ingénieurs le verront.
Ennuyeux ≠ vieux
Ennuyeux ne veut pas dire obsolète. PostgreSQL, TypeScript, React, les grands services cloud : ce sont des technologies modernes, activement développées, extrêmement capables. Ce qui les rend ennuyeuses, c’est que leurs angles vifs sont documentés, leurs modes de défaillance connus, et qu’un million d’équipes ont déjà buté sur les problèmes que vous allez rencontrer. Ennuyeux veut dire prévisible, et la prévisibilité est exactement ce que vous achetez quand vous payez des tarifs seniors.
Un signal de recrutement se cache là, que les dirigeants lisent régulièrement à l’envers. Les ingénieurs juniors courent après les stacks intéressantes ; les seniors courent après les problèmes intéressants et choisissent délibérément des outils sans surprise, pour avoir payé de leur personne la facture de 2 h du matin. Une équipe qui vous vend une architecture ennuyeuse ne manque pas d’ambition : elle vous montre ses cicatrices. L’ambition se loge dans ce que le système fait, pas dans ce dont il est fait.
La discipline a son corollaire. Quand nous dépensons vraiment le budget d’innovation, sur les systèmes d’IA par exemple, où la frontière bouge réellement chaque trimestre, nous isolons la partie séduisante derrière des interfaces ennuyeuses, nous la gardons remplaçable, et nous l’entourons d’évaluations. Le rayon d’impact de la nouveauté doit rester un module, jamais une architecture.
Concrètement : le fournisseur de modèle se tient derrière une interface dont le reste du système ignore tout, si bien qu’en changer devient une ligne de configuration et non une migration. Un harnais d’évaluation note chaque modèle candidat sur les cas réels, si bien que la décision de bascule se prend sur une mesure et non sur une tendance. La partie séduisante reste séduisante ; elle n’a simplement pas le droit de rendre le reste du système intéressant.
La stack par défaut, et les conditions pour en sortir
L’outil pratique derrière tout cela est une stack par défaut écrite : la courte liste des technologies qu’emploie un nouveau système, sauf démonstration contraire. Une base de données principale. Un langage backend que toute l’équipe lit. Un framework frontend. Des services cloud managés plutôt que de l’auto-hébergement, le choix ennuyeux consistant, côté exploitation, à payer le fournisseur cloud pour qu’il porte l’astreinte. La liste tient sur une fiche bristol, et c’est bien le but : chaque ajout doit sembler coûteux, parce qu’il l’est.
Changer le choix par défaut est permis, mais par la porte d’entrée. Un court dossier écrit : l’exigence que le défaut actuel ne satisfait pas, le chiffre qui le prouve, le chemin de migration à l’entrée et le chemin de repli à la sortie. Puis un essai sur un périmètre non critique, avant que quoi que ce soit d’exposé aux clients n’en dépende. Les équipes qui tiennent ce rituel adoptent peut-être une technologie nouvelle par an, délibérément, et elle tient. Les autres en adoptent cinq par accident et en gardent deux ; les trois restantes demeurent quand même en production, à moitié migrées, et prélèvent une rente sans fin.
Les questions à poser à votre prochain prestataire
Qui maintiendra ce système en troisième année, et à quel prix ? Quelle est la taille du vivier de recrutement sur cette stack, et qu’advient-il du calendrier le jour où l’un de ces frameworks est abandonné ? Pourquoi cette seconde base de données, en chiffres ? À quoi ressemble le runbook d’astreinte, et un ingénieur qui n’a pas construit le système saurait-il le suivre ? Des réponses vagues ne signalent pas une architecture : elles signalent un passif déguisé en démo.
La technologie ennuyeuse est ce qui permet à un logiciel de rester un actif au lieu de devenir un projet de recherche muni d’une page de connexion. C’est un luxe que votre entreprise peut s’offrir précisément parce qu’il n’en a pas l’air. Le haut de gamme n’est pas dans les outils. Il est dans la retenue.