Choisir sa stack technique : les critères qui comptent vraiment
Vincent
Co-fondateur, direction technique
En bref
Sur quels critères choisir la technologie d'une application métier qui doit durer ?
Quatre critères, dans cet ordre : la capacité à recruter ou remplacer un développeur sur cette technologie dans votre région, la stabilité des versions majeures et la longueur du support, la qualité de l'écosystème sur les besoins non fonctionnels (authentification, paiement, export, observabilité), et l'expérience réelle de l'équipe qui va construire. La performance brute et la modernité du langage arrivent loin derrière : elles ne sont presque jamais le facteur limitant d'une application métier.
Un client m’a demandé récemment pourquoi nous ne proposions pas le langage dont tout le monde parlait cette année-là. Ma réponse l’a surpris : parce que nous ne saurons pas recruter quelqu’un pour le maintenir en 2032.
C’est le critère que je place devant tous les autres, et il est rarement en tête des comparatifs qu’on lit en ligne.
Ce qu’on choisit vraiment
Choisir une technologie pour une application métier, ce n’est pas choisir un outil. C’est prendre un engagement sur dix ans : sur un marché du recrutement, sur un rythme de mises à jour de sécurité, sur un écosystème de bibliothèques, et sur la capacité d’une équipe que vous ne connaissez pas encore à reprendre le travail.
Les comparatifs de performance ne mesurent rien de tout cela.
1. Le recrutement, et sa géographie
La question n’est pas « cette technologie est-elle populaire ? » mais « combien de personnes compétentes sont joignables à moins d’une heure de chez vous, ou en télétravail sur votre fuseau ? ».
C’est une question locale. Une technologie très répandue à l’échelle mondiale peut être rare dans votre bassin d’emploi. Et l’application devra être maintenue par des gens qu’il faudra recruter, à un tarif de marché, dans plusieurs années.
Mon test pratique : chercher les offres publiées dans la région sur les douze derniers mois. Peu d’offres signifie deux choses — peu de candidats, et peu d’employeurs, donc un candidat qui hésitera à s’y spécialiser.
Photo : Lisa Fotios — licence CC0.
2. La stabilité et la durée du support
Deux choses à regarder, faciles à vérifier.
Le rythme des versions majeures cassantes. Un écosystème qui casse la compatibilité tous les dix-huit mois vous impose un budget de migration permanent. Ce n’est pas rédhibitoire, mais cela doit être budgété — et ça ne l’est presque jamais.
La durée du support à long terme. Combien d’années une version reste-t-elle corrigée pour les failles de sécurité ? En dessous de trois ans, vous serez en migration continue.
Ces deux informations sont publiques et prennent dix minutes à vérifier. Elles sont beaucoup plus prédictives que n’importe quel classement de popularité.
3. L’écosystème sur ce qui n’est pas votre métier
Une application métier passe l’essentiel de son code sur des sujets qui ne sont pas spécifiques : authentification, gestion des droits, envoi d’e-mails, export tableur, génération de PDF, planification de tâches, journalisation, observabilité.
Ce sont des problèmes résolus. La bonne question est : existe-t-il, dans cet écosystème, une bibliothèque mature, maintenue et éprouvée pour chacun ?
Quand la réponse est non, l’équipe réimplémente — et réimplémente en particulier des choses qu’il ne faut pas réimplémenter, comme l’authentification. C’est le meilleur moyen d’introduire une faille dans un domaine où l’on n’est pas spécialiste.
4. L’expérience réelle de l’équipe
Une équipe qui maîtrise vraiment une technologie produit mieux qu’une équipe qui découvre une technologie « objectivement supérieure ». La différence de productivité entre les deux dépasse largement l’écart entre deux langages comparables.
C’est aussi un critère honnête à exiger d’un prestataire. Demandez depuis combien de temps l’équipe pratique la technologie proposée, et sur combien d’applications encore en production. Une réponse floue est une réponse.
Photo : Janko Ferlic — licence CC0.
Photo : Lorenzo Cafaro — licence CC0.
5. La performance, et pourquoi elle arrive en dernier
Ce n’est pas qu’elle n’a pas d’importance. C’est qu’elle n’est presque jamais le facteur limitant d’une application métier.
Dans la quasi-totalité des cas que j’ai rencontrés, les problèmes de lenteur venaient d’un accès aux données mal conçu — requêtes multipliées, index absents, chargements inutiles — et non du langage. Changer de langage n’aurait rien réglé ; corriger une requête a divisé le temps de réponse par vingt.
La performance devient un critère de premier plan dans des cas identifiables : très forte volumétrie, calcul intensif, temps réel strict. Si vous n’êtes pas dans un de ces cas, la placer en tête vous fera passer à côté des critères qui comptent.
Ce que nous utilisons, et pourquoi
Nous travaillons majoritairement en Java/Spring côté backend et en TypeScript côté front, avec PostgreSQL pour les données. Ce n’est pas un choix d’enthousiasme, c’est un choix de durabilité.
Java parce que le vivier de recrutement est profond partout en France, que les versions à support long durent des années, et que l’écosystème couvre tout ce qui n’est pas notre métier. TypeScript parce qu’il apporte du typage là où il manquait, sans exiger un profil rare. PostgreSQL parce que les contraintes d’intégrité y sont sérieuses, et qu’une application métier vit ou meurt avec la cohérence de ses données.
Aucun de ces choix n’est spectaculaire. C’est précisément ce qu’on attend d’une décision qui engage dix ans.
Les technologies que nous écartons, et sur quel critère
Le sujet est délicat parce qu’il touche à des préférences personnelles. Je m’en tiens donc à des critères observables, jamais à un jugement sur la qualité intrinsèque d’un outil.
Une technologie portée par une seule entreprise, sans gouvernance ouverte. Le risque n’est pas l’abandon brutal, il est le changement unilatéral de licence ou de modèle économique. C’est arrivé assez souvent ces dernières années pour ne plus être théorique.
Une technologie dont la version majeure change tous les ans avec des ruptures. Le coût de suivi devient supérieur au bénéfice. Une application vit huit ans ; une technologie qui casse la compatibilité tous les dix-huit mois impose cinq migrations sur cette durée.
Une technologie sans réponse claire sur trois sujets ennuyeux : l’authentification, les accès concurrents à la base, et la gestion des tâches de fond. Si ces trois points demandent chacun une bibliothèque tierce peu maintenue, l’assemblage sera fragile — et c’est là que se joue l’exploitation, pas dans la partie visible.
L’erreur que j’ai commise
Choisir une technologie parce qu’elle résolvait élégamment le problème le plus difficile du projet.
C’était vrai : elle le résolvait. Mais ce problème représentait 5 % du travail. Les 95 % restants — formulaires, listes, exports, droits, envois de courriels — étaient plus pénibles à écrire avec elle qu’avec un outil banal.
La leçon que j’en tire, et que j’applique depuis : choisir pour le cas courant, pas pour le cas difficile. Le cas difficile s’isole, et il peut parfaitement être traité par un composant séparé, dans une autre technologie s’il le faut. Le cas courant, lui, se répète des centaines de fois et détermine le rythme de tout le projet.
C’est aussi ce qui explique pourquoi les choix les plus ennuyeux vieillissent le mieux.
La question à poser en conception
Une seule, et elle clôt généralement le débat : si toute l’équipe actuelle partait demain, combien de temps faudrait-il pour qu’une nouvelle équipe soit opérationnelle ?
Une technologie qui rend cette réponse courte vous protège. Une technologie qui la rend longue crée une dépendance — envers votre équipe, ou envers votre prestataire. Et une dépendance, même confortable au début, se paie toujours au moment où l’on voulait justement être libre.