20 ans de développement : ce qui a vraiment changé

Comment le développement est-il passé du serveur physique au cloud ?

En 2000, livrer une application voulait dire commander une machine, la câbler, l'installer, puis prier pour qu'elle tienne la charge. Le cycle se comptait en semaines. Aujourd'hui, une infrastructure entière se décrit dans un fichier et se déploie en minutes.

• 2000-2008 — le serveur physique. Une application, une machine. La montée en charge signifiait acheter du matériel plus gros. Le moindre pic de trafic était un risque.

• 2008-2014 — la virtualisation. Plusieurs serveurs logiques sur une même machine. Meilleure densité, mais l'exploitation restait lourde.

• 2014-2020 — le cloud et les conteneurs. On loue la capacité à la demande. Docker puis Kubernetes rendent une application portable et reproductible d'un environnement à l'autre.

• Depuis 2020 — le serverless et le managé. On ne pense plus au serveur du tout : on paie l'exécution, pas la machine allumée.

Le vrai changement n'est pas technique, il est économique. On a remplacé un gros investissement matériel par une dépense proportionnelle à l'usage. Cela abaisse la barrière d'entrée — mais transfère la complexité vers l'architecture.

Pourquoi la manière de coder a-t-elle autant changé ?

Le langage n'a pas disparu, mais l'écosystème autour du code a explosé. Écrire une fonctionnalité représente désormais une fraction du travail réel.

• Du monolithe aux services. On découpe les grosses applications en briques indépendantes, déployables séparément. Plus de souplesse, mais aussi plus de points de défaillance à orchestrer.

• L'automatisation du cycle de vie. Tests, intégration et déploiement continus (CI/CD) transforment la mise en production d'un événement redouté en routine quotidienne.

• L'open source comme socle. Une application moderne repose sur des centaines de dépendances externes. La productivité grimpe, la surface de sécurité aussi.

• L'infrastructure devient du code. On versionne l'infrastructure comme le reste, ce qui rend un environnement reproductible et auditable.

Concrètement, un développeur d'aujourd'hui passe autant de temps à assembler, sécuriser et exploiter qu'à écrire des lignes de code. C'est là que se jouent la fiabilité et le coût réel d'un projet.

Comment la donnée est-elle devenue le centre de gravité ?

En vingt ans, la donnée est passée du statut de sous-produit à celui d'actif principal. Les architectures se sont réorganisées autour d'elle.

• Des bases relationnelles seules aux systèmes spécialisés selon l'usage : recherche, cache, analytique, séries temporelles.

• Le stockage massif à bas coût a rendu possible de tout conserver, quitte à trier plus tard.

• Le temps réel est devenu une attente standard : tableaux de bord vivants, événements traités au fil de l'eau.

La conséquence pour vous : la qualité de vos décisions dépend directement de la qualité de votre modèle de données. Une architecture data bâclée coûte cher longtemps, bien après la mise en production.

Quel rôle l'intelligence artificielle joue-t-elle vraiment dans le développement ?

Depuis 2022, l'IA générative a modifié la façon d'écrire du code et d'imaginer des produits. Il faut séparer la réalité de l'effet de mode.

• L'assistance au code accélère les tâches répétitives et la génération de première ébauche. Elle ne remplace pas le jugement d'architecture ni la responsabilité d'un choix technique.

• L'IA comme fonctionnalité produit — recherche sémantique, résumé, classification — devient accessible sans entraîner soi-même un modèle.

• Le coût et la dépendance. Appeler un modèle a un prix par requête et crée un lien fort avec un fournisseur externe. Cela se pilote comme une décision d'architecture, pas comme un gadget.

Mon principe : l'IA est un levier, jamais une finalité. La question utile n'est pas « comment mettre de l'IA », mais « quel problème métier précis je résous, et à quel coût ».

Que retenir de cette évolution pour vos décisions techniques ?

La tendance de fond est claire : on abstrait la complexité pour aller plus vite, mais cette complexité ne disparaît pas — elle se déplace vers l'architecture et l'exploitation. Deux repères pratiques :

• Choisir la sobriété. La technologie la plus récente n'est pas la plus adaptée. Une architecture simple, comprise et maîtrisée bat une architecture à la mode que personne ne sait exploiter.

• Assurer la continuité. Le vrai risque d'un projet n'est pas le choix d'un langage, c'est la rupture entre la stratégie, le code et la production. C'est précisément ce que je supprime en portant seul cette continuité : architecture, développement, exploitation — un seul responsable.

Comprendre d'où vient le développement moderne aide à ne pas répéter les erreurs coûteuses : sur-ingénierie, dépendances subies, dette technique invisible. C'est cette lecture que j'applique à chaque projet.