Comment bien choisir sa stack technologique

Choisir une technologie pour un projet, c'est un peu comme choisir une maison : tu vas y vivre longtemps, alors mieux vaut ne pas se tromper. Sauf que contrairement à une maison, tu ne changes pas de stack tous les 5 ans. Tu peux te retrouver avec une dette technique qui te suit pendant une décennie.

J'ai fait ce choix une dizaine de fois dans ma carrière. Pour des startups, des grandes entreprises, des projets persos. Voici ma méthode, avec des exemples concrets de ce qui a marché et de ce qui a foiré.

Les mauvaises raisons qui m'ont déjà piégé

Avant de donner ma méthode, laisse-moi te partager les erreurs que j'ai faites ou vues :

C'est ce que j'ai vu sur LinkedIn ce matin

Un ancien CTO a voulu tout migrer sur un framework qu'il avait découvert dans un post viral. Résultat : 6 mois de perdu, une équipe démotivée, et un retour en arrière qui a coûté le double.

Tout le monde l'utilise

J'ai choisi MongoDB pour un projet en 2015 parce que c'était la hype. Le projet nécessitait des transactions complexes et des relations solides. On est passés sur PostgreSQL 3 mois plus tard, après avoir réécrit la moitié du code.

Le CTO veut absolument tester ça

Un client a imposé Elixir pour une API REST toute simple. Pas parce que le problème le nécessitait, mais parce que le CTO voulait se faire plaisir. Six mois après son départ, l'équipe a tout réécrit en PHP.

C'est ce qu'on a toujours fait

À l'inverse, j'ai vu des équipes refuser d'évoluer. Java 8, Struts, IE11. Parce que ça marche. Jusqu'au jour où plus personne ne voulait travailler sur le projet, et que le recrutement est devenu impossible.

Ma méthode en 5 critères

Je n'ai pas de boule de cristal, mais je pose ces 5 questions à chaque fois. Si au moins 4 sont OK, le choix est bon.

1. Quel problème spécifique est-ce qu'on résout ?

C'est la question la plus importante, et pourtant celle qu'on saute le plus souvent.

Exemple concret :

L'année dernière, je devais choisir entre Java/Spring Boot et Go pour un nouveau service de traitement de flux.

• Le besoin : un service qui consomme des événements Kafka, les transforme, et les publie sur un autre topic. Rien de plus.

• Java/Spring Boot : je maîtrise, l'équipe aussi, l'écosystème Kafka est excellent.

• Go : plus performant, plus léger, binaires statiques, mais l'équipe doit apprendre.

Ce que j'ai choisi : Spring Boot. Pourquoi ? Parce que la perf de Go n'était pas un facteur différenciant pour ce projet. Ce n'était pas un service à très haut débit. La maintenabilité et la vitesse de développement étaient plus importantes que les économies de RAM.

Quelques correspondances qui marchent :

2. Est-ce que l'équipe peut suivre ?

Un framework génial que personne ne maîtrise, c'est un passif, pas un actif.

Exemple réel :

À Colismart, on utilise Java/Spring Boot. Pas parce que c'est la techno la plus récente ou la plus excitante. Mais parce que :

• Toute l'équipe maîtrise Java

• Recruter un développeur Java à Conakry prend 2 semaines, pas 3 mois

• Les seniors Java peuvent former les juniors rapidement

• La documentation interne existe déjà

Ce que je regarde concrètement :

• Combien de membres de l'équipe maîtrisent déjà cette techno ?

• Si je dois recruter, combien de temps pour trouver un profil ?

• Est-ce que la courbe d'apprentissage est raisonnable pour mon équipe actuelle ?

Un contre-exemple : j'ai vu une startup choisir Rust pour son backend. Le CTO était un expert Rust. Mais le premier développeur qu'ils ont recruté a mis 6 mois à être productif. La startup a fermé avant.

3. Est-ce que l'écosystème est suffisamment mature ?

Une techno, ce n'est pas juste un langage. C'est tout ce qui tourne autour.

Ce que je vérifie toujours :

• Documentation : est-ce que je peux trouver la réponse à un problème courant en 2 minutes ?

• Communauté : est-ce que des gens posent des questions et obtiennent des réponses ?

• Packages : est-ce qu'il existe une solution pour l'authentification, les fichiers, les queues, le monitoring ?

• Rétrocompatibilité : est-ce que la version 3 casse tout ce qu'on a fait en version 2 ?

Exemple : J'ai hésité entre Prisma et TypeORM pour un projet NestJS.

• Prisma : excellent DX, documentation claire, migrations automatiques.

• TypeORM : plus mature, plus de fonctionnalités, mais documentation moyenne et maintenance irrégulière.

J'ai choisi Prisma. Pourquoi ? Parce que la documentation était tellement bonne que mon développeur junior était productif en 2 jours. Avec TypeORM, il aurait passé une semaine à chercher comment faire une migration simple.

4. De quelles performances a-t-on vraiment besoin ?

Pas besoin d'une Formule 1 pour aller chercher le pain. Sois honnête.

Exercice pratique :

Avant de choisir, estime :

• Combien d'utilisateurs simultanés au pic ?

• Quel volume de données sur 3 ans ?

• Quelle latence est acceptable ?

Exemple : Pour Colismart, j'ai choisi Laravel. Pas Node.js, pas Go. Pourquoi ?

• Trafic estimé : quelques centaines d'utilisateurs par jour

• Latence acceptable : 1-2 secondes

• Volume de données : quelques Go par an

Laravel gère ça les yeux fermés. Choisir Go ou Node.js aurait complexifié le recrutement, ralenti le développement, et n'aurait apporté aucun bénéfice mesurable.

Inversement : J'ai travaillé sur un système de paiement qui traitait 10 000 transactions par seconde. Là, on n'a pas choisi Laravel. On a choisi Java avec des microservices, Kafka, et PostgreSQL optimisé. La perf était un critère non négociable.

5. Est-ce que je pourrai maintenir ça dans 3 ans ?

C'est le critère le plus important, et celui qu'on néglige le plus souvent sous l'excitation du nouveau projet.

Questions à se poser :

• Est-ce que cette techno sera encore populaire dans 3 ans ?

• Est-ce que je trouverai encore des développeurs pour travailler dessus ?

• Est-ce que les coûts d'hébergement et d'infrastructure sont prévisibles ?

• Est-ce que la migration vers autre chose sera facile si on se trompe ?

Exemple concret :

J'ai choisi Spring Boot pour un projet d'assurance. Le projet durera au moins 5 ans. Mon raisonnement :

1. Spring Boot est là depuis 2014. Il sera encore là dans 5 ans.

2. Java est dans le top 3 des langages les plus utilisés depuis 20 ans.

3. Je trouve un développeur Java en 2 semaines.

4. Héberger une app Spring Boot sur AWS coûte ~50€/mois. Prévisible.

Si j'avais choisi un framework moins connu (Micronaut, par exemple), le risque aurait été plus élevé. Pas forcément un mauvais choix, mais un risque à connaître.

Comment j'applique cette méthode dans ma pratique

Quand je dois choisir une techno, je sors un tableur et je note chaque critère de 1 à 5 :

Spring Boot gagne, non pas parce que c'est le plus sexy, mais parce que c'est le plus rationnel pour mon contexte.

Et si tu te trompes ? Ce n'est pas grave.

La meilleure techno n'existe pas. J'ai fait des mauvais choix. Tout le monde en fait. L'important c'est de :

1. Identifier vite que tu t'es trompé (ne pas laisser l'ego prendre le dessus)

2. Avoir un plan de sortie (comment migrer sans tout casser)

3. Documenter pourquoi tu changes (pour que le prochain évite la même erreur)

Et surtout, n'oublie pas : une équipe motivée avec une techno moyenne battra toujours une équipe démotivée avec la meilleure techno du monde.