Deux ans d'aléas, un socle qui n'a pas bougé

Aucun développement ne se déroule comme prévu. Ce n'est pas un défaut d'organisation, c'est la nature du travail : sur trois ans, le marché bouge, les bibliothèques changent de licence, les frameworks sortent des versions majeures, l'équipe change, et le produit lui-même découvre à qui il parle. La vraie question n'est donc pas « comment éviter les imprévus », mais qu'est-ce qui, dans une application, doit rester debout quand tout le reste bouge.

Nous avons un cas d'école sous la main. BuyStep, la marketplace B2B de l'énergie dont nous développons la plateforme depuis l'été 2024, a changé de framework, de base de données, de moteur de mappage, de fournisseur d'e-mails, de système de facturation et de technologie de présentation. Elle a jeté deux gabarits achetés et réinitialisé quatre fois ses migrations. Elle tourne aujourd'hui sur une API .NET 10 et un portail Next.js 16 — et son modèle de domaine est toujours celui d'août 2024.

Pour écrire cet article, nous n'avons rien reconstitué de mémoire : vingt-six commits réels ont été extraits de l'historique Git, recompilés avec le SDK de leur époque, relancés sur une base de données neuve et photographiés. Vingt-cinq ont redémarré. Les chiffres viennent de Git, pas d'une estimation.

Trois semaines pour poser le socle, deux ans pour en profiter #

Le dépôt démarre le 1ᵉʳ août 2024. Ce qui est mis en place dans les vingt premiers jours est déterminant pour tout ce qui suit :

• Une architecture en couches — Domain, Application, Infrastructure, WebApi, Utils — posée dès les premiers commits, avant qu'il y ait quoi que ce soit à afficher.
• Un modèle de traduction générique : une entité, une table de traductions associée. Pas de colonnes nom_fr, nom_en, pas de fichiers de ressources dupliqués par langue.
• Une intégration continue le jour un. Le fichier de pipeline est corrigé huit fois dans la même journée avant de fonctionner. C'est fastidieux, et c'est le meilleur investissement du projet : deux ans plus tard, cette pipeline bloque encore ce qui casse.
• Les migrations de base en code, versionnées avec l'application, et non un schéma administré à la main quelque part.

Aléa 1 — le gabarit acheté, jeté deux fois #

Partir d'un gabarit du commerce est une décision de démarrage raisonnable : elle achète du temps. Elle coûte en octobre 2024, quand il faut supprimer plus de 240 000 lignes d'anciens fichiers de présentation pour les remplacer par une feuille de style plus légère. Et elle recoûte en janvier 2025, quand un second gabarit est importé en bloc, l'ancienne page étant conservée à côté sous un nom en OLD.

Le point important : ces deux nettoyages n'ont touché que la couche de présentation. Aucune entité, aucun service applicatif, aucune migration n'a été impactée. Un projet où le gabarit acheté aurait infusé jusqu'au modèle de données aurait payé ces deux épisodes au prix d'une réécriture.

Aléa 2 — les migrations réinitialisées quatre fois #

C'est le symptôme le plus visible d'un projet jeune : l'historique des migrations de base de données est remis à plat quatre fois. En décembre 2024, la plupart des fichiers d'octobre et novembre disparaissent. En mars 2025, treize nouvelles migrations remplacent les précédentes. En octobre 2025, 54 fichiers sont supprimés d'un coup. En avril 2026, tout l'historique est compressé en une seule migration initiale.

Faut-il s'en alarmer ? Tant que le schéma est dérivé du modèle en code et non l'inverse, non : une réinitialisation est une opération d'hygiène, pas une perte. Ce qui serait grave, c'est de réinitialiser un schéma dont la vérité vit dans la base de production et nulle part ailleurs.

Aléa 3 — les dépendances qui changent de contrat sous vos pieds #

Aucune de ces décisions n'était au plan de départ, et chacune a été forcée par l'extérieur :

• Le client de recherche passe d'une bibliothèque abandonnée à la bibliothèque officielle en juin 2025 — un changement d'API complet, mené dans une branche dédiée.
• La bibliothèque de mappage passe en licence payante et se met à vérifier un jeton au démarrage. En avril 2026, elle est remplacée par un générateur de code qui produit les mêmes conversions à la compilation : plus de réflexion à l'exécution, plus de licence à renouveler.
• La documentation d'API abandonne l'outil historique pour l'OpenAPI natif du framework, après un aller-retour reverté le jour même.
• L'envoi d'e-mails change de fournisseur en décembre 2025 ; le stockage de fichiers part sur un objet compatible S3 avec CDN en avril 2026 ; la facturation maison — factures, virements, détails de paiement — est supprimée en septembre 2025 au profit d'un modèle entièrement délégué au prestataire de paiement.

Le fil conducteur est toujours le même : ces bibliothèques étaient confinées à la couche Infrastructure. On remplace un adaptateur, pas un système. Le jour où un mappeur devient payant, l'équipe qui a laissé ses appels remonter dans les services métier réécrit trois cents fichiers ; celle qui les a gardés derrière une interface en réécrit dix.

Aléa 4 — la montée de version qui ne passe pas #

Mars 2025, passage de .NET 8 à .NET 9. Sur le papier, une opération de routine : chaque fichier projet, chaque paquet de la couche d'accès aux données, la suite de tests. En pratique, c'est la fenêtre la plus chargée de la première année — quarante-huit commits, dont vingt-trois entre 22 h et 6 h — et la seule que nous n'ayons jamais réussi à faire redémarrer.

Un an plus tard, la même opération vers .NET 10 prend une journée, au milieu d'une bascule bien plus large. Ce n'est pas le framework qui a changé de difficulté : c'est le projet qui, entre-temps, avait des tests, une pipeline, une configuration en variables d'environnement et une image conteneurisée reproductible.

Aléa 5 — le travail qui ne se voit pas, et qu'il faut quand même financer #

Cet épisode n'est pas isolé. Septembre 2024 : un mois entier de modélisation du domaine — API REST, DTO, premiers tests — sans un pixel de changement. Le 3 décembre 2025 : douze commits dans la journée — pipeline, télémétrie, gestion des commissions — et des captures rigoureusement identiques à celles de la veille.

C'est la source de malentendu la plus fréquente entre une équipe technique et ceux qui financent son travail. Ce qui se voit et ce qui coûte ne sont pas corrélés, et un pilotage de projet qui ne regarde que les écrans finit toujours par arbitrer contre le socle — c'est-à-dire contre la capacité du produit à encaisser l'aléa suivant.

Aléa 6 — l'équipe qui change #

L'historique compte jusqu'à quatre contributeurs actifs sur un mois, et des mois entiers à un seul. Février 2026 ne contient qu'un commit et une retouche de texte. À l'inverse, octobre 2025 est écrit par une seule personne, en onze fusions en production consécutives.

Ce qui absorbe cette variation, ce n'est pas l'héroïsme : ce sont les conventions écrites. En octobre 2025, la configuration passe entièrement en variables d'environnement, l'application est dockerisée, un jeu de données d'amorçage est écrit et les commandes de build sont documentées dans le dépôt. À partir de là, un nouvel arrivant peut faire tourner le projet sans demander à personne. C'est la seule réponse durable au turnover, et accessoirement la condition pour qu'une assistance par IA soit utile plutôt que bruyante.

Ce que le socle a permis : remplacer la moitié de la pile en trois semaines #

Entre le 24 mars et le 12 avril 2026, le dépôt est restructuré en monorepo, la base passe de MySQL à PostgreSQL — les deux bases distinctes étant refusionnées en une —, le framework monte en .NET 10, le portail est réécrit en Next.js et l'administration Blazor est supprimée du dépôt. Trois semaines.

Aucune de ces opérations n'a demandé de réécrire le domaine métier. C'est exactement ce qu'une architecture en couches est censée acheter, et c'est rarement vérifié en conditions réelles : ici, ça l'a été quatre fois de suite. Détail qui dit tout : la veille de la suppression de l'administration Blazor, des commits corrigeaient encore sa navigation. On répare jusqu'au bout ce qu'on va retirer, parce que le retrait est prévu, daté, et sans double maintenance derrière.

Ce qui a remplacé la discipline : des garde-fous exécutables #

Un socle ne tient pas tout seul ; il tient parce que quelque chose vérifie qu'il tient, à chaque livraison. Sur la même fenêtre où le volume de code a explosé, quatre choses sont apparues :

1. Les tests d'intégration quittent la base en mémoire pour un vrai PostgreSQL éphémère en conteneur, remis à zéro entre les tests. Une base en mémoire ne rejoue ni les migrations ni le SQL propre au moteur : elle cache précisément les bugs qu'une migration massive produit.
2. Des tests d'architecture vérifient automatiquement que les couches ne se traversent pas. C'est la seule façon de garantir qu'un socle reste un socle quand quinze personnes — ou quinze sessions d'assistant — écrivent dedans.
3. Une séparation nette entre tests unitaires (quelques secondes) et tests d'intégration (quelques dizaines de secondes), pour que personne n'ait de raison de sauter les premiers.
4. Une pipeline en cinq étapes qui bloque tout ce qui casse, et des tests de bout en bout sur le parcours de paiement ajoutés en août 2026 — là où une erreur coûte de l'argent réel.

Le test le plus honnête : savez-vous reconstruire votre projet d'il y a six mois ? #

C'est la question que cette rétrospective a fini par poser, et nous la reprenons désormais pour nos propres audits. Reconstruire un commit ancien, appliquer ses migrations, le faire démarrer : si l'opération échoue, ce n'est presque jamais le code qui est en cause. C'est un secret devenu obligatoire sans être documenté, une dépendance qui arrête le processus quand son service est absent, un port occupé, une migration qui ne rejoue pas.

Autrement dit, c'est un test de maîtrise de l'environnement, et il est impitoyable. Le détail de l'outillage qui le fait tourner est décrit dans un article à part ; ce que l'assistance par IA a changé dans la conduite de ces migrations l'est dans celui-ci.

Ce que nous en retenons #

• Décidez tôt ce qui ne bougera pas. Le découpage en couches et le modèle de données se paient au départ ou dix fois plus tard. Tout le reste est remplaçable, et le sera.
• Confinez les dépendances externes. Une bibliothèque qui change de licence ou d'API ne doit jamais coûter plus qu'un adaptateur.
• Un schéma dérivé du code se répare ; un schéma administré à la main se subit. Quatre réinitialisations de migrations n'ont rien cassé pour cette raison.
• Financez ce qui ne se voit pas. Les mois sans un pixel de changement sont souvent les plus structurants.
• Rendez le projet démarrable sans vous. Configuration en variables d'environnement, conteneurs, jeu de données d'amorçage, commandes documentées : c'est la réponse au départ d'un développeur comme à l'arrivée d'un nouveau.
• Automatisez la vérification du socle. Tests sur une vraie base, tests d'architecture, pipeline bloquante : sans eux, un socle se dégrade en silence.

C'est la façon dont nous concevons les applications métier que nous développons, et dont nous reprenons celles qui existent déjà. Si votre plateforme a quelques années, que plus personne ne sait la reconstruire et que chaque évolution coûte plus cher que la précédente, c'est précisément le diagnostic que nous savons poser. Premier échange offert, devis sous 48 h, et hébergement en France si vous le souhaitez.