L'université vous note sur ce que vous savez, donc le code complexe rapporte des points. Les clients vous notent sur une seule chose : le produit règle-t-il leur problème, et vite ?
C'est de cet écart que naît la sur-ingénierie. La solution : construire le plus simple qui marche, et n'ajouter de la complexité que quand de vrais utilisateurs en ont besoin.
Je vois les deux systèmes de notation de près. J'ai terminé mon master en intelligence artificielle en juin 2026 tout en construisant des produits pour des entreprises. Les deux récompensent des habitudes presque opposées.
Qu'est-ce que la sur-ingénierie ?
La sur-ingénierie, c'est construire un logiciel plus complexe que le problème ne l'exige. On ajoute des couches, des outils et des fonctions pour des utilisateurs et des problèmes qui n'existent pas encore.
Pensez à un examen de maths. Le professeur donne des points pour chaque étape montrée, donc les longues réponses sont bien notées.
Un client n'est pas un professeur. Il veut seulement la réponse, et chaque étape en trop, c'est du temps d'attente.
La sur-ingénierie rend un produit plus long à faire, plus dur à changer et plus cher à faire tourner. Et le client n'en voit rien.
Pourquoi l'université récompense-t-elle la complexité ?
Parce qu'un projet universitaire a une autre mission. Il doit prouver que vous maîtrisez la théorie.
Un schéma de base de données détaillé, un algorithme astucieux et plusieurs couches d'architecture montrent tous des connaissances. Le jury voit l'effort, donc l'effort rapporte des points.
Ce n'est pas une erreur. Les bases apprises à l'université sont réelles, et vous en aurez besoin. Le problème, c'est l'habitude : emporter l'idée « complexe veut dire bon » dans une entreprise où personne ne note la complexité.
À quoi ressemble la sur-ingénierie dans une startup ?
Les mêmes schémas reviennent sans cesse :
- Des microservices pour cinq utilisateurs. Découper l'appli en nombreux petits services avant d'avoir testé une seule appli simple.
- Du cache avant d'avoir du trafic. Le cache consiste à garder des copies prêtes des données pour charger les pages plus vite. Il règle un problème de vitesse que vous n'avez pas encore.
- Du code pour des fonctions qui n'existent pas. Des « frameworks » flexibles pour des besoins futurs que personne n'a confirmés.
- De nouveaux outils lus dans l'article de la semaine dernière. Chacun ajoute quelque chose à apprendre, mettre à jour et réparer.
Chaque choix paraît malin seul. Ensemble, ils transforment un produit de deux mois en produit de dix mois.
Une startup doit-elle choisir les microservices ou un monolithe ?
Commencez par un monolithe.
Un monolithe est une seule application qui contient toutes les parties de votre produit. Les microservices découpent le produit en nombreuses petites applications qui se parlent par le réseau.
Les microservices aident les très grandes équipes. Pour une startup, ils multiplient le travail : plus de serveurs, plus de connexions qui peuvent tomber, plus d'endroits où chercher quand quelque chose casse.
L'expert logiciel Martin Fowler a écrit que presque toutes les réussites en microservices ont commencé par un monolithe devenu trop gros, puis découpé. Les systèmes construits en microservices dès le départ, ajoute-t-il, ont presque toujours fini en grande difficulté (Fowler, 2015).
Construisez d'abord une application propre. Découpez-la plus tard, seulement si la croissance vous y oblige.
Qu'est-ce que le principe YAGNI, et comment aide-t-il ?
YAGNI signifie « You Aren't Gonna Need It », soit « vous n'en aurez pas besoin ». C'est une règle de l'Extreme Programming, une méthode utilisée par beaucoup d'équipes : ne construisez pas quelque chose maintenant parce que vous pensez en avoir besoin plus tard (Fowler, 2015).
Avant de construire quoi que ce soit, posez trois questions :
- Un vrai utilisateur en a-t-il besoin aujourd'hui ? Pas « pourrait en avoir besoin », aujourd'hui.
- Est-ce que ça règle un problème métier ou rapporte de l'argent ?
- Qu'est-ce qui casse si on le reporte ? Si la réponse est « rien », reportez.
Si une fonction échoue aux trois, mettez-la sur une liste « plus tard ». Vous ne perdez rien, car vous pourrez toujours la construire quand le besoin sera réel.
Projet universitaire ou réalité du marché : qu'est-ce qui change ?
| Projet universitaire | Réalité du marché | |
|---|---|---|
| Qui note | Un jury | Des clients qui paient |
| Ce qui rapporte | Montrer ses connaissances | Régler un problème vite |
| La complexité | Un signe d'effort | Un coût que paie le client |
| Les délais | Des mois de planification | Des semaines jusqu'à la première version |
| La réussite | Une bonne note | Des clients qui reviennent |
La colonne de gauche, c'est la façon d'échouer sans le voir pendant deux ans. Puis on découvre que personne ne voulait ce qu'on a construit.
Quand la complexité vaut-elle la peine ?
Simple ne veut pas dire bâclé. Certaines parties d'un produit méritent tout votre soin dès le premier jour :
- La sécurité. Le serveur vérifie les prix et les droits, jamais le navigateur.
- Les sauvegardes. Quotidiennes, automatiques et testées.
- Les écritures financières. Jamais modifiées, seulement corrigées par de nouvelles écritures. J'explique pourquoi dans ne modifiez jamais une écriture financière.
- Le modèle de données. La façon de stocker l'information est difficile à changer plus tard.
Mettez votre effort technique là, et gardez tout le reste simple. J'explique à quoi ressemble un bon produit simple dans minimum viable ne veut pas dire effort minimum.
Pourquoi est-ce important en Algérie ?
Beaucoup de diplômés algériens transforment leur projet de fin d'études, le PFE, en première startup. C'est un bon départ : l'idée a été étudiée et l'étudiant connaît son sujet.
Mais le PFE a été construit pour un jury. En faire un produit, c'est retirer ce qui a impressionné le jury et garder ce qui aide le client.
Le client algérien juge vite, lui aussi. La plupart testeront votre produit sur un téléphone moyen, avec une connexion qui coupe. Une appli simple qui charge vite bat une appli maligne qui se fige.
J'explique comment garder les coûts bas dans pourquoi les applis chères meurent avant leur lancement. Et ce qui change entre une démo et un vrai produit dans prototype ou production.
Quelles erreurs font les nouveaux fondateurs ?
- Concevoir pour des millions avant d'avoir dix utilisateurs. Construisez pour ceux que vous avez.
- Choisir ses outils pour paraître malin. Choisissez des outils que vous savez réparer à 2 h du matin.
- Construire des fonctions « pour plus tard ». Appliquez YAGNI.
- Sauter la sécurité et les sauvegardes pour gagner du temps. Gardez simplicité et sécurité ensemble.
- Mesurer le progrès en lignes de code. Mesurez-le en clients qui reviennent.
Que faire cette semaine ?
- Aujourd'hui : listez toutes les parties de votre système. Marquez celles dont aucun utilisateur actuel n'a besoin.
- Cette semaine : pour chaque fonction prévue, posez les trois questions YAGNI.
- Cette semaine : si votre appli est découpée en nombreux services pour peu d'utilisateurs, envisagez de la regrouper en une seule.
- Avant le lancement : confirmez sauvegardes, vérifications côté serveur et écritures financières sûres.
- Chaque semaine ensuite : n'ajoutez de la complexité que quand un vrai problème d'utilisateur le demande.