Il existe une méthode fiable pour repérer un logiciel construit pour impressionner ceux qui l’ont écrit plutôt que pour servir ceux qui le possèdent : comptez les technologies. Le système avec 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 des technologies enthousiasmantes
Une technologie nouvelle vous facture trois fois. D’abord en inconnues inconnues : les modes de défaillance dont personne n’a encore parlé sur un blog, découverts à 2 h du matin dans votre production. Ensuite au recrutement : chaque choix exotique réduit le vivier des personnes capables de maintenir le système et fait monter leur prix. Enfin en longévité : le framework enthousiasmant de cette année a une chance sur deux d’être abandonné d’ici cinq ans - les outils éprouvés, eux, ont déjà survécu à leurs extinctions.
Les trois factures se composent entre elles. La base de données exotique tombe en panne d’une manière non documentée, ce qui reste 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, parce que le vivier de candidats sur cette compétence précise relève de l’erreur d’arrondi. Pendant ce temps, le framework dont elle dépend annonce sa « nouvelle direction passionnante », formule d’éditeur qui signifie une réécriture de tout ce que vous aviez construit sur l’ancienne. Ce n’étaient pas trois risques distincts ; c’était un seul risque, acheté trois fois.
Ces coûts tombent après le départ de l’agence. C’est précisément pour cela que les agences sont structurellement attirées par les technologies enthousiasmantes - le bénéfice pour le CV est pour elles, la facture de maintenance est pour vous. Aligner ces intérêts relève autant de la conception du contrat que de l’ingénierie : c’est une des raisons pour lesquelles nous garantissons notre travail et proposons d’exploiter ce que nous construisons.
Comment la collection se constitue
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 une entreprise de mille ingénieurs pour une bonne pratique applicable à une équipe de six. Un schéma en microservices a l’air plus professionnel qu’un monolithe assumé. Chaque choix ajoute une pièce mobile, et les pièces mobiles se multiplient : 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, pour toujours.
La défense tient en une règle ennuyeuse appliquée au moment de la revue : toute technologie hors de la stack par défaut doit acheter son entrée avec une exigence mesurable que le choix par défaut ne peut pas satisfaire. « 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 - parce qu’un seul des deux peut montrer un historique.
L’innovation est un budget. Dépensez-le sur votre produit, là où vos clients le voient - pas sur votre infrastructure, où seuls vos ingénieurs le voient.
Ennuyeux ≠ vieux
Ennuyeux ne veut pas dire hérité. PostgreSQL, TypeScript, React, les services cloud grand public - ce sont des technologies modernes, activement développées et 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à rencontré les problèmes que vous allez rencontrer. Ennuyeux veut dire prévisible, et c’est la prévisibilité que vous achetez quand vous payez des tarifs seniors.
Il y a là un signal de recrutement que les dirigeants interprètent régulièrement à l’envers. Les ingénieurs juniors courent après les stacks intéressantes ; les ingénieurs seniors courent après les problèmes intéressants et choisissent délibérément des outils endormis, parce qu’ils ont payé personnellement la facture de 2 h du matin pour l’excitation. Une équipe qui vous vend une architecture ennuyeuse ne manque pas d’ambition - elle vous montre ses cicatrices. L’ambition doit se loger dans ce que le système fait, pas dans ce dont il est fait.
Cette discipline a un corollaire : quand nous dépensons vraiment le budget d’innovation - comme sur les systèmes d’IA, où la frontière bouge réellement chaque trimestre - nous isolons la partie enthousiasmante derrière des interfaces ennuyeuses, nous la gardons remplaçable, et nous l’entourons d’évaluations. Le rayon d’impact de la nouveauté doit être un module, jamais une architecture.
Concrètement, cela veut dire que le fournisseur de modèle se tient derrière une interface dont le reste du système ignore tout, de sorte qu’en changer soit une modification de configuration et non une migration. Cela veut dire un harnais d’évaluation qui note chaque modèle candidat sur vos cas réels, pour que la décision de changer soit une mesure et non une déclaration de mode. La partie enthousiasmante reste enthousiasmante - elle n’a simplement pas le droit de rendre le reste du système intéressant.
La stack par défaut, et comment en changer
L’outil pratique derrière tout cela est une stack par défaut écrite : la courte liste des technologies qu’utilise un nouveau système, sauf preuve du 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, côté exploitation, consiste à 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 - par la porte d’entrée. Un court dossier écrit : l’exigence que le choix actuel ne peut pas satisfaire, le chiffre qui le prouve, le chemin de migration à l’entrée et la porte de sortie. Puis un essai sur quelque chose de non critique, avant que quoi que ce soit d’exposé aux clients n’en dépende. Les équipes qui appliquent ce rituel adoptent peut-être une nouvelle technologie par an, délibérément, et elle tient. Celles qui ne l’appliquent pas en adoptent cinq par accident et en gardent deux - les trois autres restent quand même en production, à moitié migrées, à faire payer un loyer éternel.
Les questions à poser à votre prochain prestataire
Qui maintiendra ce système en troisième année, et combien coûtera cette personne ? Quelle est la taille du vivier de recrutement sur cette stack - et qu’advient-il de notre calendrier quand 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 pourrait-il le suivre ? Si les réponses restent vagues, l’architecture est un passif déguisé en démo.
La technologie ennuyeuse, c’est ainsi qu’un logiciel reste un actif au lieu de devenir un projet scientifique avec une page de connexion - autrement dit : c’est un luxe que votre entreprise peut s’offrir précisément parce qu’il n’en a pas l’air. Le premium n’est pas dans les outils. Il est dans la retenue.