Choix de stack technique : pourquoi la mode ne sert pas le produit

Une équipe de quatre développeurs qui met en place Kubernetes pour servir 800 utilisateurs par jour ne fait pas de l'ingénierie : elle fait de la mode. Le produit n'ira pas plus vite, ne tombera pas moins souvent, et l'équipe passera désormais un quart de son temps à opérer une plateforme qu'elle n'a pas besoin d'opérer.

La question n'est jamais « cette technologie est-elle bonne ? ». Elle est toujours « quel problème avons-nous, et cette technologie le résout-elle mieux que ce que nous avons déjà ? ».

Le vrai critère : qu'est-ce que l'utilisateur y gagne ?

Un utilisateur ne perçoit qu'un nombre limité de choses : la rapidité, la fiabilité, la clarté, la sécurité de ses données, et le rythme auquel ses problèmes sont résolus. Aucune de ces perceptions n'est corrélée au nom de votre orchestrateur de conteneurs.

Une stack se juge donc sur sa contribution à quatre variables :

• Le délai entre une idée et sa mise en production.
• Le taux d'incidents et le temps de remise en service.
• Le coût d'exploitation rapporté à l'usage réel.
• La capacité à recruter et à intégrer un développeur en moins d'un mois.

Toute technologie qui n'améliore aucune de ces quatre variables est un coût déguisé en progrès.

Les trois pièges les plus fréquents

Le piège du passage à l'échelle imaginaire. On conçoit pour un million d'utilisateurs alors qu'on en a mille. On paie immédiatement la complexité d'une architecture distribuée pour un besoin qui n'existera peut-être jamais — et si l'entreprise atteint réellement ce volume, elle aura de toute façon les moyens de refondre avec des données réelles.

Le piège du curriculum vitae. Un développeur qui souhaite apprendre une technologie n'est pas un mauvais développeur, c'est un signe de curiosité saine. Mais le produit d'une entreprise n'est pas un support d'apprentissage. La bonne réponse est un budget de formation et des projets internes, pas l'introduction d'une brique critique que personne ne maîtrisera dans dix-huit mois.

Le piège du découpage prématuré. Découper en microservices une application dont on ne comprend pas encore les frontières métier revient à figer de mauvaises frontières, en ajoutant la latence réseau et la complexité de déploiement. Le découpage se mérite : il vient quand plusieurs équipes se gênent réellement, pas avant.

Une grille d'arbitrage en cinq questions

Avant d'introduire une technologie, faites-la passer par ces cinq filtres. Si vous ne pouvez pas répondre à trois d'entre eux, la réponse est non.

1. Quel problème mesuré cette technologie résout-elle ? Avec un chiffre : temps perdu, incidents, coût.
2. Que se passe-t-il si on ne fait rien pendant six mois ?
3. Combien de personnes dans l'équipe savent l'exploiter en production, aujourd'hui, sans aide extérieure ?
4. Quel est le coût de sortie si le choix s'avère mauvais dans un an ?
5. Quelle est l'option la plus ennuyeuse qui règle 80 % du problème ? Souvent : une base de données relationnelle bien indexée, un serveur applicatif unique, un cache, et des sauvegardes testées.

Choisir une technologie ennuyeuse, volontairement

Il existe une notion utile en ingénierie : le budget d'innovation. Une équipe ne peut se permettre qu'un ou deux paris technologiques simultanés. Tout le reste doit être le plus banal possible — largement documenté, largement recruté, éprouvé.

Ce n'est pas du conservatisme. C'est l'allocation d'une ressource rare : l'attention de l'équipe. Chaque technologie non standard consomme de l'attention qui n'ira pas dans le produit. Réservez vos paris là où ils créent un avantage compétitif visible pour le client — et nulle part ailleurs.

Quand la modernisation est justifiée

Il ne s'agit pas de tout figer. Une migration se justifie pleinement dans quatre cas :

• La technologie actuelle n'est plus maintenue ou ne reçoit plus de correctifs de sécurité.
• Elle empêche de recruter : le vivier de candidats est devenu marginal.
• Elle coûte plus cher à exploiter que l'alternative, migration comprise, sur un horizon de dix-huit mois.
• Elle bloque un besoin métier réel, démontré par des cas concrets, pas par une intuition.

Dans ces situations, la migration progressive — un périmètre isolé à la fois, avec les deux systèmes en parallèle — reste presque toujours supérieure à la réécriture complète.

Ce type d'arbitrage, tenu dans la durée et expliqué à la direction comme à l'équipe, est le cœur du travail de un directeur technique externalisé.

FAQ

Faut-il utiliser Docker et Kubernetes dans une PME ?

Docker, oui dans la plupart des cas : il standardise les environnements et simplifie le déploiement, pour un coût d'apprentissage faible. Kubernetes, rarement : il ne se justifie qu'avec plusieurs équipes, de nombreux services et un besoin réel d'élasticité. En dessous, une plateforme managée ou quelques serveurs bien administrés coûtent moins cher et tombent moins souvent.

GraphQL ou REST pour une nouvelle application ?

REST reste le choix par défaut : plus simple à mettre en cache, à sécuriser et à déboguer, et connu de tous les développeurs. GraphQL devient pertinent quand plusieurs clients très différents consomment les mêmes données avec des besoins de champs hétérogènes, ou quand le nombre d'allers-retours réseau dégrade réellement l'expérience mobile.

Comment trancher quand l'équipe est divisée sur un choix technique ?

Demandez à chaque camp d'écrire une page : problème, options, critères, conséquences à dix-huit mois, coût de sortie. La plupart des désaccords se dissolvent à l'écrit, car ils portent en réalité sur des critères implicites différents. S'il reste un désaccord, la décision revient au directeur technique — et elle est documentée, datée et réexaminable.