La prémisse
L'ingénierie logicielle moderne est une discipline dont il devient plus difficile de parler chaque année. Le vocabulaire a enflé plus vite que le métier sous-jacent n'a changé : chaque cadriciel se dit un paradigme, chaque cloud se dit une plateforme, chaque assistant se dit un agent.
Derrière le bruit, le travail est resté reconnaissable. Une équipe prend un besoin d'affaires, choisit une architecture avec laquelle elle peut vivre, livre une première version qui survit au contact des utilisateurs, puis la maintient à travers trois ans de changement sans la réécrire. Les équipes qui font cela de façon constante en 2026 partagent un petit nombre d'habitudes, et presque aucune ne concerne le choix du cadriciel.
Ce texte porte sur ce que l'ingénierie logicielle moderne livre réellement — et sur là où l'IA a changé, et n'a pas changé, l'ingénierie elle-même.
Le coût d'une mauvaise architecture n'a pas baissé
Les cadriciels ont évolué. Le coût d'un mauvais choix fondamental, lui, n'a pas baissé.
Une affirmation courante en 2026 est que le développement assisté par l'IA a rendu le logiciel bon marché. Il a rendu certains logiciels plus rapides. Plus rapide n'est pas la même chose que moins cher, parce que le travail que comprime l'assistance de l'IA — la frappe — était rarement la partie coûteuse. Les parties coûteuses sont toujours les mêmes : choisir la bonne architecture, modéliser correctement le domaine, décider quoi livrer et quoi refuser, et maintenir le résultat pendant des années.
Un modèle de données mal jugé reste un problème étalé sur plusieurs trimestres. Une frontière d'authentification mal jugée laisse encore fuir les données des clients. Une histoire de déploiement mal jugée réveille encore l'ingénieur de garde à 3 h 14. Aucune de ces classes d'erreur n'est résolue par une frappe plus rapide. Elles sont résolues par le jugement senior à l'étape de la conception — la partie du travail que l'IA assiste, mais ne remplace pas.
Les équipes qui livrent du logiciel en 2026 passent plus de temps sur les décisions architecturales précoces qu'il y a cinq ans, parce que le coût de se tromper se compose plus vite à travers un code augmenté par l'IA.
Des défauts ennuyeux, assumés là où ça compte
La pile par défaut de SDEN pour le web et le mobile est délibérément conservatrice : Next.js avec TypeScript à l'avant, PostgreSQL avec Prisma ou Drizzle sur la couche de données, Node.js ou un cadriciel comme NestJS sur la surface d'API. Le mobile passe par défaut à Flutter ou React Native à moins que le produit n'ait besoin d'une intégration profonde à la plateforme. Le but n'est pas que ce soient les choix les plus à la mode. C'est que ce sont les choix qu'une petite équipe senior peut encore maintenir dans trois ans.
Là où nous sommes assumés, c'est sur les frontières : des API typées de bout en bout, rendues côté serveur par défaut, aucune donnée non typée qui traverse entre le serveur et le client, un pipeline d'IC qui bâtit et déploie chaque commit sur la branche principale, et un processus de publication assez automatisé pour que l'ingénieur qui a livré le changement ne soit pas l'ingénieur qui surveille le déploiement.
Ce ne sont pas des choix excitants. Ce sont les choix qui rendent le travail excitant possible plus tard — parce que l'équipe ne dépense pas son énergie sur les fondamentaux.
Les motifs qui survivent à la deuxième année
La plupart des projets logiciels semblent bien aller dans les six premiers mois. Les tests intéressants viennent à la deuxième année, quand les ingénieurs d'origine ont changé de poste, que le produit a accumulé des cas marginaux, et que la clientèle s'est étendue au-delà des hypothèses de conception. Les motifs qui survivent à ce test sont les ennuyeux : des frontières de modules explicites, un modèle de domaine documenté dans le code plutôt que dans un wiki, un registre de décisions architecturales pour chaque choix non évident, et une suite de tests que quelqu'un peut encore exécuter.
Les motifs qui ne survivent pas sont ceux qui dépendaient de la mémoire d'un seul ingénieur, du fait que les défauts d'un cadriciel restent constants, ou de l'hypothèse que personne ne voudrait jamais revoir ce code. On le veut toujours.
Le parti pris de SDEN sur chaque mandat va vers le motif ennuyeux, accepté explicitement et documenté. Nous échangerons l'astuce contre la lisibilité sur la deuxième année de chaque projet.
Trois habitudes derrière chaque code que nous remettons
Ce ne sont pas des aspirations. Ce sont les défauts d'exploitation sur chaque mandat, inscrits dans le contrat de mandat.
Typé de bout en bout
TypeScript sur toute la pile, sans frontière non typée entre le serveur et le client. Si un champ change dans la base de données, le frontal refuse de compiler tant que le changement n'est pas reconnu. C'est le filet de sécurité le moins cher pour une grande équipe que nous connaissions.
Registres de décisions architecturales
Chaque choix non évident obtient un ADR d'une page dans le dépôt : ce que nous avons décidé, ce que nous avons considéré, pourquoi nous en avons choisi un plutôt que l'autre. Les futurs ingénieurs — y compris les nôtres — les lisent dès le premier jour.
Déploiement ennuyeux
Le déploiement est automatisé, observable et réversible. N'importe quel ingénieur de l'équipe peut livrer en production; n'importe quel ingénieur de l'équipe peut revenir en arrière. Le processus de publication n'est pas un rituel.
Le code que vous pouvez encore lire dans trois ans
La mesure honnête d'un mandat, c'est ce que la prochaine équipe pense du code.
Un code qui vieillit bien n'a pas une astuce unique. Il a une centaine de petites bontés : des noms significatifs, des modules dimensionnés pour qu'une personne les tienne en tête, des tests qui expliquent l'intention derrière le code, pas de code mort qui traîne pour confondre le prochain lecteur, et un registre de décisions architecturales à chaque jonction où un futur ingénieur devrait autrement deviner.
Quand SDEN remet un code, le test est concret : un ingénieur senior qui rejoint le projet devrait être productif en moins d'une semaine, sans visite guidée. S'il ne le peut pas, nous n'avons pas terminé.
C'est la moitié ennuyeuse du travail. C'est aussi la moitié qui détermine si le produit survit au prochain changement dans l'équipe.
Logiciel et mobile —
les questions qu'on nous pose.
Des réponses directes aux questions qu'on nous pose le plus souvent. Si la vôtre n'y est pas, écrivez à l'équipe.