On ne finit jamais un logiciel. On le prépare à survivre.

« finir » Je pense que, ce mot n’a pas trop sa place en ingénierie logicielle.

D’abord Un projet démarre avec deux familles d’exigences : les exigences fonctionnelles (besoins métiers, automatisation, problèmes concrets) et les exigences non fonctionnelles (techniques), celles qui déterminent si l’application survivra.

Parmi les exigence technique j’aimerai aborder certain point dans mes lignes qui vont suivre

La Scalabilité : anticiper la montée en charge

Une application peut répondre au besoin métier et être inutilisable en production. Pourquoi ? Parce que Les performances n’ont pas été pensées dès le départ.

La montée en charge ne doit pas être une surprise. 100 utilisateurs aujourd’hui, 10 000 demain. Deux approches souffre généralement a nous pour remédier à cette limitation:

• Scalabilité verticale : augmenter la puissance machine(RAM CPU etc…)
• Scalabilité horizontale : multiplier les instances c’est a dire démarrer la même app sur plusieurs machine puis répartir la charge

Ce choix structure l’architecture dès le premier jour. L’ignorer, c’est préparer une refonte dans six mois.

E/S Bloquant vs non-bloquant : le modèle de concurrence

à ce niveau à mon avis La performance vas dépendre de comment l’application gère la concurrence.

Multi-thread bloquant : un thread par requête. Quand une opération I/O se lance (BDD, API), le thread attend. Pour 1000 requêtes simultanées, il faut 1000 threads. Simple, mais limité : consommation mémoire élevée, coût du changement de contexte. C’est Java Servlets classique, PHP-FPM, Rails.

Non-bloquant asynchrone : un seul thread (ou petit pool) gère toutes les requêtes via une event loop. Le thread ne bloque jamais : il passe à autre chose pendant les I/O. Résultat : des milliers de connexions avec peu de ressources. C’est Node.js, Spring WebFlux, FastAPI.

Le choix dépend du contexte :

• Multi-thread : peu de concurrence, traitements CPU intensifs, simplicité du code
• Non-bloquant : forte concurrence, beaucoup d’I/O, APIs à fort trafic

Encore une décision qui se prend dès la conception, pas après.

Maintenance : le vrai coût

Le jour où vous avez fini de développer une application, c’est le jour où vous l’avez tuée.

Un logiciel vivant évolue. Nouvelles règles métier, nouveaux besoins, nouvelles contraintes techniques. Si chaque évolution oblige à modifier le code existant, chaque changement devient un risque : bugs, régressions, dette technique.

D’où le principe : fermée à la modification, ouverte à l’extension pour introduire mon point suivant.

Conception extensible : le couplage fait tout

Ce principe se décide à la conception, pas après.

Le Couplage fort : des new partout, dépendances directes entre classes. Toute nouvelle version oblige à toucher au code source. Rendre ça maintenable ? Bonne chance.

Le Couplage faible : les classes dépendent d’interfaces, pas d’implémentations concrètes. On peut introduire une nouvelle version sans modifier le code existant. L’application continue de fonctionner et accepte de nouvelles extensions. C’est l’inversion de contrôle et l’injection de dépendances.

La conception avant le code

La qualité d’un logiciel se joue avant même la première ligne de code.

Les frameworks (Spring, NestJS, Angular, React) ne sont pas juste pour faire jolie ou suivre la tendance. Ils imposent des structures éprouvées qui facilitent performance, testabilité et évolution.

Egalement les design patterns (Strategy, Factory, Observer), l’inversion de contrôle, l’injection de dépendances ne sont pas académiques. Ce sont des outils concrets pour construire des applications qui survivent aux versions, aux équipes et au temps.

Les grandes plateformes (AWS, Azure, Kubernetes) évoluent constamment parce qu’elles sont conçues pour ça.

---

Un logiciel n’est jamais « terminé ». Il est soit prêt à évoluer, soit déjà en train de mourir.