Ce que personne ne dit quand le projet démarre
Le projet est lancé. Le développeur est compétent. L’équipe est motivée. La démo fonctionne. Tout le monde est content.
Six mois passent. Puis douze. Puis dix-huit.
Et là, quelque chose change. Le site met 8 secondes à charger. Ajouter une nouvelle fonctionnalité prend trois semaines au lieu de trois jours. Le prestataire initial est injoignable — ou trop cher pour toucher à ce qu’il a construit. Une refonte s’impose, mais le devis que vous recevez est trois fois supérieur au budget initial.
Ce n’est pas de la malchance. C’est la facture différée d’un mauvais choix technique pris 18 mois plus tôt.
J’ai vu ce scénario se jouer une dizaine de fois. Pas parce que les gens concernés étaient incompétents. Parce que les mauvais choix techniques ont une propriété particulièrement traître : ils ne font pas mal tout de suite.
Pourquoi le problème n’est pas visible au départ
Un mauvais choix structurel ne casse rien à court terme. Le code tourne. Les fonctionnalités existent. Les utilisateurs s’en servent.
Le problème est dans ce qu’on ne voit pas : la rigidité qui s’accumule. Chaque nouvelle fonctionnalité construite sur de mauvaises fondations la rend un peu plus fragile. Chaque contournement ajouté pour gérer une limitation non prévue est un noeud de plus dans un fil déjà embrouillé.
Au bout d’un an, le système fonctionne encore — mais il est devenu difficile à comprendre pour quelqu’un qui n’a pas tout construit de l’intérieur. Au bout de deux ans, il est souvent impossible à maintenir sans risque de tout casser.
C’est ce qu’on appelle la dette technique. Et comme toute dette, elle porte des intérêts.
Les 5 choix qui coûtent le plus cher
1. Choisir une technologie parce qu’elle est à la mode
Le problème avec les technologies hype, c’est qu’elles sont présentées comme des solutions universelles. Kubernetes est présenté comme le standard de déploiement. Les microservices comme l’architecture incontournable. Le dernier framework JavaScript comme la seule façon sérieuse de construire un frontend.
Le problème, c’est que ces outils ont été conçus pour résoudre des problèmes à une échelle qui n’est pas la vôtre.
Kubernetes gère des centaines de services en production chez Netflix ou Google. Pour une TPE de 3 personnes avec un trafic de 500 visiteurs par jour, c’est une complexité opérationnelle disproportionnée. Personne dans l’équipe ne sait vraiment le maintenir. Le premier incident de production devient une crise.
Même raisonnement avec les microservices sur un MVP. Vous n’avez pas encore validé votre produit. Vous avez besoin de changer vite, de tout rebrancher, d’itérer. Une architecture en microservices impose une coordination, une gestion des erreurs distribuées et une observabilité que vous n’avez ni le temps ni les ressources de gérer correctement à ce stade.
La règle que j’applique : choisir la technologie la plus simple qui résout le problème. Pas la plus impressionnante. Pas celle dont tout le monde parle. Celle qui est éprouvée, bien documentée, et que vous (ou votre prestataire) serez encore capables de maintenir dans deux ans.
2. Ne pas prévoir la maintenance dès le premier jour
Un site livré. Le client est content. Le prestataire passe à autre chose.
Deux ans plus tard : le client veut ajouter un module de réservation. Le prestataire original a fermé sa société. Il n’y a pas de documentation. Le code est hébergé sur un compte personnel que personne ne contrôle. Personne ne sait comment le serveur est configuré.
Ce scénario se produit régulièrement. Il n’est pas inévitable, mais il requiert qu’on pose les bonnes questions avant de signer.
À qui appartient le code ? Avez-vous accès au dépôt Git ? Y a-t-il une documentation d’architecture, même sommaire ? Quelqu’un d’autre que le développeur initial est-il capable de reprendre le projet ?
Ces questions semblent administratives. Elles sont en réalité techniques. Un code sans documentation et sans transfert de propriété n’est pas vraiment livré. C’est une dépendance déguisée.
3. L’outil tout-en-un qui fait tout… mal
Wix, Squarespace, les constructeurs de sites propriétaires : ils ont leur place. Pour un site vitrine simple, un portfolio, une page de présentation, ils font le travail rapidement.
Le problème, c’est quand les besoins évoluent au-delà de ce qu’ils permettent.
J’ai vu des clients bloquer pendant des mois sur l’intégration d’une fonctionnalité spécifique — un calculateur de devis, un espace client, une synchronisation avec leur outil de gestion — parce que la plateforme sur laquelle leur site était construit ne le permettait pas nativement. Et personnaliser une plateforme fermée pour faire ce qu’elle n’est pas prévue pour faire coûte bien plus cher que de construire la même chose sur une base open source.
La migration, elle, est souvent impossible sans tout refaire. Les données sont enfermées dans un format propriétaire. Le SEO accumulé dépend d’URLs que vous ne contrôlez pas.
La question à poser avant de choisir une plateforme : “dans 3 ans, si mes besoins ont évolué, est-ce que je pourrai migrer sans tout perdre ?“
4. Ignorer la scalabilité dès le départ
Ce point est souvent mal compris. Il ne s’agit pas de prévoir une architecture pour des millions d’utilisateurs quand vous en avez cent. Ce serait de l’over-engineering.
Il s’agit de ne pas prendre des décisions qui vous bloqueront si vous passez de 100 à 1 000 utilisateurs. Ce sont deux choses différentes.
Un exemple concret : stocker des données dans des fichiers plats plutôt que dans une base de données relationnelle parce que “pour l’instant ça suffit”. Ca suffit. Jusqu’au moment où vous avez besoin de faire des recherches, des filtres, des agrégations. Là, vous devez tout migrer — et la migration de données est coûteuse, risquée, et jamais au bon moment.
Un autre : ne pas gérer les sessions utilisateurs correctement, parce que l’application n’a qu’un seul serveur. Quand vous passez à plusieurs instances pour tenir la charge, les sessions sont perdues. Refactoriser l’architecture d’authentification à mi-parcours coûte 3 à 5 fois plus cher que de le faire correctement dès le début.
La règle ici : ne pas prévoir pour des millions, mais éviter les décisions qui ferment des portes.
5. La dette technique jamais remboursée
“On fera proprement plus tard.”
Cette phrase est l’une des plus coûteuses qu’on puisse prononcer dans un projet technique. Non pas parce que plus tard n’arrivera jamais — il peut arriver. Mais parce que “plus tard” dans un projet en cours signifie “quand on aura du temps libre”, ce qui en pratique ne se produit pas.
La dette technique acceptée consciemment a du sens dans certains cas. Quand on doit sortir une version rapidement pour valider une hypothèse, prendre un raccourci est une décision rationnelle. Le problème n’est pas la dette en elle-même. C’est quand elle s’accumule sans jamais être remboursée.
Chaque nouvelle fonctionnalité construite sur des fondations fragiles aggrave la situation. Les raccourcis s’empilent. Le code devient difficile à lire, difficile à modifier sans effets de bord. Les développeurs qui rejoignent le projet mettent des semaines à comprendre comment tout est connecté.
Au bout d’un moment, le coût de rembourser la dette est tellement élevé qu’on préfère continuer à l’accumuler. C’est le piège.
Ce que ça coûte vraiment : les chiffres
Les chiffres qui suivent sont tirés d’études reconnues dans l’industrie, notamment les travaux du NIST (National Institute of Standards and Technology) sur le coût de correction des bugs :
- Correction d’un bug en phase de développement : 1x
- Correction du même bug après la livraison en production : 5 à 10x
- Refonte d’architecture après 18 mois d’accumulation de dette : 3 à 8x le coût initial
- Migration d’une plateforme propriétaire vers du développement sur mesure : difficile à estimer, souvent imprévisible parce qu’on ne sait pas ce qu’on va trouver
Ces ratios ne sont pas des hypothèses. Ils correspondent à ce que j’observe en pratique quand j’interviens sur des projets existants.
Un choix technique pris en 30 minutes en début de projet peut générer 40 heures de travail non planifié 18 mois plus tard. Multiplié par un taux journalier moyen, les sommes deviennent rapidement significatives pour une TPE.
Comment l’éviter : les bonnes questions à poser
Je ne crois pas aux recettes universelles. Mais il y a des questions dont les réponses révèlent beaucoup sur la solidité d’un choix technique.
Avant de choisir une technologie :
- Cette technologie est-elle adaptée à la taille de notre équipe et à notre niveau de compétence ?
- Sera-t-elle encore maintenue activement dans 3 ans ?
- Combien de développeurs connaissent cette technologie (et donc pourront reprendre le projet) ?
Avant de signer avec un prestataire :
- À qui appartient le code à la livraison ?
- Dans quel état sera la documentation ?
- Comment le projet sera-t-il maintenu après la livraison ?
Avant de faire un choix d’architecture :
- Ce choix ferme-t-il des portes si nos besoins évoluent dans 18 mois ?
- Quelqu’un d’autre que la personne qui l’a conçu peut-il comprendre et modifier ce système ?
Sur la dette technique :
- Quand et comment cette dette sera-t-elle remboursée ?
- Existe-t-il un processus pour garder la qualité du code sous contrôle dans la durée ?
La dernière recommandation que je donne souvent : préférer les technologies boring. Pas glamour, pas à la une des conférences tech. Mais stables, documentées, avec une communauté large et des années de recul. PostgreSQL plutôt que la dernière base de données distribuée prometteuse. Un framework web éprouvé plutôt que celui sorti il y a 8 mois. Le choix ennuyeux est souvent le choix judicieux.
FAQ
Comment savoir si mon projet actuel a une dette technique importante ?
Quelques signaux concrets : les développeurs hésitent à toucher certaines parties du code (“personne ne sait ce que ça fait vraiment”) ; ajouter une fonctionnalité simple prend anormalement longtemps ; les bugs réapparaissent après correction ; personne ne peut expliquer l’architecture globale du système de façon claire. Si vous reconnaissez deux ou trois de ces signes, la dette est probablement significative.
Est-ce qu’il faut toujours tout refactoriser ?
Non. Refactoriser a un coût, et ce coût doit être mis en regard de la valeur que ça apporte. Réécrire entièrement un système qui fonctionne, même imparfaitement, est rarement la bonne décision. La bonne approche est généralement de rembourser la dette progressivement, au fil des nouvelles fonctionnalités, en améliorant les parties du code qu’on touche. Un refactoring total ne se justifie que quand le coût de maintenir l’existant dépasse clairement le coût de repartir de zéro — et c’est rare.
Comment évaluer la qualité du code livré par un prestataire ?
Si vous n’êtes pas développeur, demandez une revue de code par un tiers de confiance avant de valider la livraison. Vérifiez également des indicateurs non techniques : le code est-il versionné dans un dépôt Git auquel vous avez accès ? Y a-t-il des tests automatisés ? La documentation existe-t-elle ? Ces éléments ne garantissent pas la qualité, mais leur absence est un signal d’alarme.
C’est quoi une bonne architecture pour une TPE ?
Simple, documentée, et maintenue par une seule personne (ou une petite équipe). Une application monolithique bien structurée vaut mieux qu’une architecture microservices sous-maintenue. Une base de données relationnelle standard avec des migrations claires vaut mieux qu’une solution NoCode sophistiquée dont le schéma est impossible à comprendre. L’objectif n’est pas d’impressionner — c’est de construire quelque chose qui sera encore compréhensible et modifiable dans deux ans.
Vous avez un projet existant et vous sentez que quelque chose ne va pas sous le capot ? Je fais des audits de code. Me contacter