Choisir sa stack technologique : ce que nos projets nous ont appris

La question arrive presque toujours sous la même forme : « React ou Vue ? », « WordPress ou du sur-mesure ? ». C’est rarement la bonne question. Une stack technologique se juge sur ce qu’elle coûte et ce qu’elle permet sur toute la vie du projet, pas sur la réputation du framework le jour de la signature.

Voici les critères que nous utilisons, puis trois cas clients où une stack correcte sur le papier s’est révélée le mauvais choix.

Quels critères pour choisir sa stack technique ?

Les guides sur le sujet se recoupent, et l’essentiel y est. Quatre critères comptent vraiment.

La nature du projet. Un site vitrine, une application métier et une API de traitement de données n’ont pas les mêmes contraintes. Le premier dépend entièrement de son référencement, la deuxième de la fiabilité de ses données, la troisième de sa capacité à encaisser la charge.

Qui va écrire le code, et qui va le lire ensuite. Le meilleur framework ne sert à rien si personne autour du projet ne le maîtrise. Ce critère vaut aussi pour le prestataire : une technologie qu’il connaît à fond produit moins de bugs qu’une technologie à la mode qu’il n’a jamais utilisée.

L’écosystème. Une communauté active, une documentation à jour, des libraries maintenues. Un composant qu’il faut écrire soi-même parce qu’il n’existe pas dans l’écosystème est un composant à maintenir seul pendant des années.

La charge à encaisser. Une architecture taillée pour cent utilisateurs devient un goulet d’étranglement à dix mille. Mais l’inverse est bien plus fréquent : une architecture dimensionnée pour un trafic qui n’arrivera jamais, et qui coûte cher à faire tourner dès le premier mois.

Le critère que les guides oublient : qui maintient le projet dans trois ans ?

Un projet numérique passe quelques mois en développement et plusieurs années en exploitation. C’est là que le choix de stack se paie, ou s’amortit.

Les questions utiles ne portent pas sur les frameworks mais sur la suite : qui applique les mises à jour de sécurité ? Que se passe-t-il si le prestataire n’est plus disponible ? Un autre développeur peut-il reprendre le code sans tout réécrire ? Où sont les sauvegardes, et quelqu’un a-t-il déjà essayé d’en restaurer une ?

Avec une stack répandue, déployée depuis un dépôt Git et documentée, ces questions ont déjà leur réponse. Avec une stack exotique, ou un site modifié directement en production sans historique, chaque réponse a un coût.

Sur la boutique reprise décrite plus bas, il n’y avait ni dépôt Git ni documentation, et les mises en production se faisaient à la main sur le serveur. Rien que la prise en main (retrouver les accès, comprendre comment le site était déployé et ce que faisaient les modules) a représenté trois jours de travail avant la première correction.

Trois cas où le bon choix sur le papier était le mauvais

Un site de vente en ligne invisible sur Google

Un site de vente par abonnement avait été construit comme une SPA (single-page application ; React, Vue ou Angular, le problème est le même). Le code était propre, les balises meta correctes. Les pages étaient pourtant mal indexées : Google reçoit une page vide et doit exécuter le JavaScript pour voir le contenu, ce qu’il fait de façon irrégulière.

La stack était bonne pour une application. Elle était mauvaise pour un site dont les ventes dépendent de la recherche Google. La leçon que nous en avons tirée : dès que le référencement compte, le rendu se fait côté serveur (Nuxt, Astro), et la SPA reste réservée aux outils internes.

Après coup, la correction n’est pas une retouche : il faut réécrire la façon dont les pages sont générées, ce qui revient à refaire une bonne partie du site. C’est pour cela que ce choix se prend avant la première ligne de code.

Un boîtier qui cochait toutes les cases, sur un réseau en cours d’extinction

Une entreprise qui exploite des installations sans personnel sur place voulait en ouvrir l’accès à distance, à des visiteurs ponctuels. Elle avait déjà acheté un contrôleur GSM dont la fiche technique répondait à tout : relais, alimentation, carte SIM, boîtier étanche.

Deux problèmes, indépendants l’un de l’autre. Le module radio était en 2G uniquement, alors que les opérateurs éteignent la 2G en France métropolitaine entre fin septembre et fin décembre 2026, d’après le calendrier publié par l’Arcep : la durée de vie du boîtier se comptait en mois. Et le boîtier fonctionnait par whitelist de numéros appelants, sans API ni journal d’événements, ce qui rendait impossible un accès temporaire, valable une heure pour une seule personne.

Il a été remplacé par un routeur 4G à relais pilotable par API. Un composant peut correspondre à chaque ligne du cahier des charges et rester le mauvais choix, parce que le réseau ou l’écosystème sur lequel il repose est en fin de vie.

Une boutique reprise avec cinquante-six extensions

Une boutique en ligne a été rachetée, son site WooCommerce compris. Dans le code : cinquante-six extensions installées, dont deux pour le SEO, deux pour les sauvegardes, une de gestion à distance du site installée par l’ancien prestataire, et plusieurs modules sur mesure dont personne ne connaissait l’auteur.

La tentation était de tout refaire. Ce n’était pas la bonne décision : la boutique fonctionnait, les commandes tournaient, les paiements étaient branchés. Le problème n’était pas WordPress, c’était l’accumulation sans arbitrage. Le travail consiste à documenter, retirer les doublons, reprendre la main sur les accès, puis seulement décider ce qui mérite d’être réécrit.

Les licences de ces extensions représentaient près de 1 500 € par an, dont une partie en doublon. Le nettoyage se fait extension par extension, en vérifiant à chaque fois ce que l’extension fait réellement sur le site.

Quand il ne faut pas changer de stack

Le cas précédent illustre une règle plus générale : sur un projet existant, remplacer la stack est presque toujours plus cher et plus risqué que l’améliorer.

Un distributeur B2B nous a confié le développement d’une API pour son catalogue produits. Son site tournait sur une version de PHP en fin de vie, sur un système d’exploitation lui aussi en fin de vie. Le réflexe aurait été de conditionner la mission à une mise à jour de la stack. Nous avons fait l’inverse : livrer l’API en restant compatible avec l’existant, et traiter la mise à jour comme un sujet à part, avec son propre budget et son propre calendrier.

Le client a obtenu ce dont il avait besoin en quelques jours. La modernisation reste sur la table, mais comme une décision qu’il prend, pas comme un passage obligé.

Ce que nous choisissons chez Avalonis, et pourquoi

Pour un projet neuf, notre base est stable depuis plusieurs années : TypeScript partout, Astro ou Nuxt pour tout ce qui doit être référencé, Vue pour les interfaces applicatives, Node.js côté serveur, PostgreSQL pour les données. Pour les flux entre outils, n8n plutôt que du code sur mesure, quand c’est possible.

Ce ne sont pas les technologies les plus récentes. Ce sont celles dont nous connaissons les limites, que d’autres développeurs peuvent reprendre, et qui se déploient depuis un dépôt Git sur des serveurs que nous administrons, avec des sauvegardes hors site vérifiées.

Cette base a bougé au moins une fois. Sur un projet, les migrations de base de données se faisaient par des fichiers SQL exécutés à la main. Deux incidents en production, sur des colonnes que le modèle déclarait obligatoires et que les anciennes lignes laissaient vides, nous ont fait passer à un outil de migration versionné, sans exception.

Cette base n’est pas imposée. Si votre équipe maîtrise PHP, ou si votre métier tourne sur Shopify, la bonne stack est celle qui s’intègre à ce que vous avez déjà. Nous l’expliquons plus en détail sur notre page méthode.

Trois questions à poser sur une proposition de stack

Avant de signer un devis, quelle que soit l’agence, trois questions suffisent à savoir si le choix a été réfléchi.

1. Pourquoi cette stack pour ce projet ? La réponse doit parler de votre projet, pas du framework.
2. Qui peut reprendre le code si votre prestataire disparaît ? La réponse attendue : un dépôt Git auquel vous avez accès, et une documentation qu’un autre développeur peut lire.
3. Que se passe-t-il au sixième mois ? Mises à jour, sauvegardes, correctifs : qui les fait, et à quelles conditions.

Si vous envisagez d’automatiser des processus plutôt que de construire un logiciel, le même raisonnement s’applique, avec des outils différents : nous l’avons détaillé dans pourquoi automatiser vos processus métier.

Questions fréquentes

Qu’est-ce qu’une stack technique ?

L’ensemble des technologies qui font fonctionner un projet : langage, framework, base de données, hébergement et outils de déploiement. Le mot est l’anglais pour « pile », parce que ces couches s’empilent les unes sur les autres.

Quelle stack choisir pour un MVP ?

Celle que votre développeur maîtrise le mieux, à condition qu’elle soit répandue. Un MVP sert à tester une idée vite, pas à préparer une charge hypothétique. Le seul point à ne pas négliger dès le départ : le rendu côté serveur si le produit doit être trouvé sur Google.

Faut-il choisir la technologie la plus récente ?

Rarement. Une technologie récente a moins de libraries, moins de développeurs disponibles et une documentation qui change. Elle se justifie quand elle résout un problème précis que les technologies établies ne résolvent pas.

Faut-il refaire un site existant sur une nouvelle stack ?

Presque jamais en première intention. Documenter, nettoyer et sécuriser l’existant coûte moins cher et produit un résultat plus vite. La réécriture se décide ensuite, sur la base de ce que le nettoyage a révélé.

---

Pour relire une proposition de stack avant de la signer, parlez-nous de votre projet.