Il existe une façon de brûler du budget logiciel que l’on nomme rarement, parce qu’elle se déguise en professionnalisme : l’overengineering, ou sur-ingénierie. Construire plus de complexité, plus de flexibilité et plus d’architecture que le problème ne le demande réellement.
C’est exactement le genre d’erreur qu’un donneur d’ordre sans grande expérience du logiciel a du mal à repérer seul, parce qu’elle ressemble à une réflexion soigneuse sur l’avenir. « Nous voulons que ce soit scalable. » « Nous voulons que ce soit pérenne. » « Nous ne voulons pas de dépendance à un fournisseur. » Des phrases raisonnables, chacune d’entre elles, et chacune une excellente couverture pour des systèmes qui coûtent trois fois plus cher que nécessaire.
Nous avons déjà écrit sur les raisons pour lesquelles les projets logiciels B2B s’enlisent si souvent, avec dix causes, des exigences floues jusqu’aux 20 % finaux qui n’en finissent pas. L’overengineering y apparaît au point 7 (la mauvaise forme de contrat), dont il découle directement. Mais il dépasse ce seul point : ce n’est pas une cause isolée, mais un schéma qui traverse plusieurs causes. La dérive du périmètre, les livraisons en « big bang », les 20 % finaux qui ne se terminent jamais. Il préfère se cacher dans le devis lui-même plutôt que de se présenter comme une erreur évidente.
Dans cet article : les schémas que nous voyons le plus souvent, pourquoi ils apparaissent, et comment nous essayons d’organiser les choses chez Tandem Studio pour ne pas y entraîner nos clients.
Le vrai coût de l’overengineering
Le problème n’est pas seulement le prix de construction. Un système simple qui tient en une seule table ne vous coûte pas seulement plus cher à construire si vous le découpez en cinq services avec chacun son API et sa base de données. Il vous coûte aussi plus cher à chaque modification, à chaque nouveau développeur à former, à chaque correction de bug qui doit traverser trois couches, et à chaque passation à un autre développeur, qui devient plus difficile parce que la complexité elle-même est devenue une barrière à l’entrée.
La facture que vous signez aujourd’hui, vous la payez chaque mois, pendant des années.
Et il y a une asymétrie désagréable : un code trop simple qu’il faut étendre plus tard ressemble à une faute du prestataire (« ils n’y ont pas réfléchi »), alors qu’un code trop complexe dont on ne se sert jamais est rarement passé explicitement par pertes et profits. Ce coût est caché dans chaque facture de maintenance qui suit, pas dans un rapport clair.
Les 8 schémas que nous voyons le plus souvent
1. Les hyperscalers par défaut. « On le met sur AWS » se dit plus facilement que « on le met sur un serveur Scaleway à Paris ». Mais pour la grande majorité des applications de PME (et même pour bon nombre de start-up SaaS), une simple VM européenne avec Postgres, votre application et Traefik suffit largement. Différence sur la facture : 20 à 100 euros par mois contre des centaines, voire des milliers. Différence de complexité : une machine que tout développeur comprend, contre un écosystème qui demande un profil spécialisé. Dans notre comparaison d’AWS, GCP, Scaleway, OVH et Hetzner, nous expliquons pourquoi nous choisissons Scaleway par défaut.
2. Des microservices pour une équipe de cinq. Les microservices sont une solution d’organisation, pas une solution technique. Ils aident quand plusieurs équipes veulent pouvoir déployer indépendamment différentes parties d’un système. Pour une PME ou une start-up avec une seule équipe, découper en six services est presque toujours une perte : plus de problèmes réseau, plus de déploiements, plus d’endroits où les données peuvent devenir incohérentes, plus de complexité opérationnelle. Un monolithe que vous découperez éventuellement plus tard, quand vous grandirez vraiment, est presque toujours le bon point de départ.
3. Kubernetes pour faire bien sur un CV. Kubernetes est puissant et assez complexe. La question n’est pas « est-ce que c’est cool ? » mais « en avons-nous besoin ? ». Pour une application qui tourne très bien sur un ou deux serveurs, docker compose avec une configuration Traefik est tout ce qu’il vous faut. Ce que vous mettez en place avec ces outils simples, n’importe quel développeur peut l’expliquer en une heure. Ce que vous mettez en place avec un cluster Kubernetes demande un spécialiste pour être modifié.
4. De la configuration pour des valeurs qui ne changent jamais. Un panneau d’administration où les taux de TVA, les modèles d’e-mail, les étapes de workflow et les règles métier de votre produit sont paramétrables, alors qu’en pratique personne ne touche jamais à ces réglages. Chaque option de configuration, c’est du code qui doit être écrit, testé, documenté et maintenu. Une valeur fixe dans le code, qu’un développeur peut modifier en cinq minutes, revient souvent moins cher qu’un bel écran d’administration ouvert une fois tous les trois ans.
5. Des « plateformes » au lieu d’applications. Certains devis ne promettent pas une application mais une « plateforme » : une base générique sur laquelle votre problème concret « viendra se poser » plus tard. Ça sonne comme une valeur ajoutée et c’est, dans 90 % des cas, de l’overengineering emballé dans de l’ambition. Vous payez deux fois : d’abord pour la couche générique, ensuite pour la mise en œuvre concrète. Et vous obtenez un produit qui ne convient vraiment à aucun cas d’usage, parce qu’il devait convenir à tous.
6. Prévoir la montée en charge pour des utilisateurs que vous n’avez pas. « Mais si on passe à un million d’utilisateurs ? » est une question qui rend facilement une architecture trois fois plus chère. La réponse honnête : si vous atteignez ce nombre, vous aurez l’argent, les clients et les connaissances pour construire quelque chose de mieux, ciblé sur ce qui coince alors réellement. Construire aujourd’hui pour un avenir qui n’arrivera peut-être jamais, c’est presque à coup sûr concevoir contre le mauvais goulet d’étranglement.
7. Des couches d’abstraction pour une seule implémentation. Une interface avec une seule implémentation derrière, « au cas où il y en aurait un jour une deuxième ». Une couche repository au-dessus d’un query builder qui est lui-même déjà une couche d’abstraction. Une factory qui renvoie toujours le même objet. Toute abstraction qui n’a pas au moins deux vrais utilisateurs est de la complexité spéculative. Pire : les abstractions précoces sont presque toujours fausses, car au moment de les concevoir vous ne saviez pas encore dans quelle direction le système allait grandir ; elles finissent donc par gêner exactement là où il ne faut pas, et sont difficiles à supprimer parce que toute la base de code a été construite autour. Ces couches d’abstraction deviennent même trop complexes pour le développement assisté par l’IA.
8. Construire sa propre authentification et sa propre gestion des utilisateurs. Connexion, mots de passe, authentification multifacteur, réinitialisation du mot de passe, gestion des sessions, contrôle d’accès par rôle, flux OAuth. Ça ressemble à quelques semaines de travail et ça finit invariablement en six mois. Et c’est une surface d’attaque que vous ne voulez pas maintenir vous-même. Demandez d’abord : ne pouvons-nous pas simplement utiliser Zitadel, Clerk, Keycloak, voire la connexion Google ou Microsoft ? Neuf fois sur dix, la réponse est oui.
Pourquoi ça arrive si souvent
Trois forces poussent structurellement à l’overengineering, et aucune n’est « les développeurs sont bêtes ».
Le prestataire gagne de l’argent avec la complexité, pas avec la simplicité. Pour un profane, une proposition avec plus de technologie paraît plus impressionnante qu’une proposition qui dit « nous construisons ça en huit semaines sur un seul serveur ». Un devis au forfait de six mois est plus attrayant pour beaucoup de prestataires qu’une mission qui peut être bouclée en six semaines.
Les développeurs ont une motivation professionnelle à utiliser des technologies intéressantes. Pas par malveillance, mais parce que leur CV et leurs futurs employeurs regardent cette expérience. Kubernetes, GraphQL et les architectures orientées événements font mieux sur un profil que « Go et un monolithe solide sur Postgres ». C’est une réalité honnête, dont vous pouvez tenir compte en tant que donneur d’ordre.
Dans votre propre organisation, personne ne peut souvent contredire les affirmations techniques. Quand le prestataire dit qu’il vous faut « un service mesh », « un bus d’événements » ou « un data lake », il y a rarement quelqu’un en interne pour juger si c’est vrai. Le réflexe par défaut : faire confiance à l’expert. Mais l’expert n’a pas toujours votre intérêt comme boussole principale.
Comment nous essayons de l’éviter chez Tandem
Notre approche n’a rien d’exotique. Elle est volontairement ennuyeuse là où l’ennui fonctionne.
Nous travaillons en spikes. En convenant pour chaque phase d’un budget délimité et d’une question concrète, il n’y a tout simplement pas de place pour « une couche dont nous aurons peut-être besoin plus tard ». Ce que nous construisons aujourd’hui résout ce que nous savons aujourd’hui. C’est un frein naturel à la complexité spéculative. Vous pouvez lire ici pourquoi nous travaillons de plus en plus en spikes plutôt qu’avec des devis classiques.
Notre stack par défaut est ennuyeuse. Go comme langage applicatif, Postgres comme base de données, Traefik comme reverse proxy, un ou deux serveurs d’application chez Scaleway, pas de Kubernetes sauf raison opérationnelle réelle. Nous montons en puissance quand un problème concret et mesurable l’exige, pas par spéculation.
Le code et les données vous appartiennent. Nous construisons délibérément de façon transmissible. Pas de technologie exotique que seuls nos collaborateurs peuvent maintenir, pas de dépendance à un cloud particulier, pas de frameworks qui vous lient à nous. Si vous voulez partir demain, vous pouvez partir avec tout. Cela nous oblige à ne pas construire de complexité dont nous serions les seuls experts. Encore un frein naturel.
Un prix fixe par phase. Aucune incitation à faire durer les heures. Plus vite et plus pragmatiquement nous pouvons bien résoudre quelque chose, mieux c’est pour les deux parties.
Se demander d’abord s’il faut vraiment le construire. Parfois, la bonne réponse à une question, c’est un bon modèle Notion, une configuration Airtable ou un flux Zapier. Nous le disons alors, même si c’est moins de travail pour nous. Un projet raté que nous n’avons pas accepté vaut mieux pour tout le monde qu’un projet que nous avons fait mais qui n’a apporté aucune valeur.
L’event sourcing : notre exception au « l’ennuyeux, c’est mieux »
Soyons honnêtes : nous aussi, nous avons des préférences. La plus visible pour qui regarde notre stack, c’est l’event sourcing comme modèle d’architecture. Ce que nous voulons souligner : dans notre contexte, l’event sourcing joue justement contre l’overengineering, pas pour lui.
La raison tient à la façon dont ce modèle s’articule avec le travail en spikes. Avec l’event sourcing, vous enregistrez chaque événement métier comme un fait immuable, au lieu de ne garder que l’état actuel. Cela permet de commencer vraiment petit aujourd’hui et d’ajouter quelque chose demain sans que les choix antérieurs vous gênent :
- Un nouvel écran ou une nouvelle vue sur les mêmes données est une nouvelle projection à côté de l’ancienne. L’existante reste intacte.
- Des fonctions d’audit ou des tableaux de bord peuvent être ajoutés plus tard, parce que tout l’historique est déjà là, sans migration rétroactive.
- Un worker asynchrone ou une intégration externe se branche sur un flux d’événements sans que le cœur du système doive changer.
- Une nouvelle fonctionnalité ajoute généralement un événement ou une projection au lieu de remanier des tables existantes.
Autrement dit : c’est un modèle qui soutient activement l’extension par itérations au lieu de la bloquer. Pour nous, c’est la façon de grandir en spikes sans devoir tout remanier à chaque nouvelle question, et donc précisément un frein au type d’overengineering dont parle cet article : vouloir tout prévoir à l’avance parce que modifier après coup coûte cher. Comme nous avons construit notre propre framework pour cela, le coût d’entrée reste limité pour nos clients. Dans notre article sur les cas où l’event sourcing est rentable pour une PME, nous détaillons cet arbitrage, y compris les cas où il vaut mieux ne pas le faire.
Cela dit, le fait d’avoir cette préférence reste une forme de biais : tous les projets ne réclament pas l’event sourcing, et nous devons rester attentifs à l’effet « nous avons ce marteau, et ce clou a l’air de faire l’affaire ». Ce que nous pouvons promettre : vous saurez de notre part pourquoi nous faisons un choix, ce qu’il coûte s’il s’avère mauvais après coup, et quelle aurait été l’alternative. Si vous voulez ensuite prendre une autre direction, très bien.
Pour conclure
Le meilleur logiciel pour la plupart des PME a l’air ennuyeux. Une technologie simple et éprouvée, peu de pièces mobiles, quelque chose en production rapidement chez de vrais utilisateurs, et de la complexité ajoutée seulement quand un problème concret le demande en pratique.
Un prestataire que cette approche enthousiasme est presque toujours un meilleur partenaire qu’un prestataire que l’architecture enthousiasme.
Vous vous demandez si une proposition posée sur votre bureau relève de l’overengineering ? Nous serons heureux de l’examiner avec vous. C’est exactement le genre de discussion que nous préférons. Prenons rendez-vous pour faire connaissance.
