Buzzwords tech : faut-il vraiment MongoDB, NoSQL, Next.js ou une stack à la mode ?
MongoDB, Next.js, Symfony ou PWA : comprendre ce que chaque brique fait et choisir une stack technique selon votre activité, pas selon la mode.
Sur cette page6 sections
« Il faut qu'on parte sur Next.js avec du NoSQL. » D'accord. Mais qu'est-ce que votre entreprise va pouvoir faire de mieux grâce à ça ? Si la réponse arrive après dix minutes de noms techniques, je préfère qu'on reprenne la discussion depuis le début.
Je ne suis pas contre les nouveaux outils. Un développeur a le droit d'aimer essayer des choses. Le problème commence quand son envie d'essayer devient votre facture, puis votre problème de maintenance pendant les années qui suivent.
Une stack, c'est l'ensemble des briques techniques d'un projet. On peut bien la choisir sans courir après chaque nouveau nom, et mal la choisir avec des technologies très connues. Le point de départ doit rester ce qu'il faut construire.
Ces termes ne sont donc pas des réponses concurrentes à une seule question. Un projet peut combiner plusieurs de ces briques. Dire « on hésite entre MongoDB et une PWA » revient un peu à hésiter entre le coffre d'une voiture et sa manière de se conduire.
Vous n'avez pas à retenir tout le dictionnaire. Votre prestataire doit surtout pouvoir expliquer quelle responsabilité remplit chaque brique, et ce qui rend celle-ci nécessaire pour votre projet.
Une base relationnelle comme MySQL se prête à une organisation en tables liées. C'est une manière souvent très lisible de représenter ce type d'activité. Avec MongoDB, on organise les données en documents, en choisissant ce qu'on regroupe et ce qu'on référence. Cette approche peut correspondre à d'autres formes de données et à leurs usages.
Ce n'est pas « des règles » contre « aucune règle ». MongoDB permet aussi de travailler avec des relations et des transactions. Sa documentation sur la modélisation et les transactions montre que le choix demande une vraie conception. La flexibilité n'enlève pas la nécessité de savoir ce qu'on enregistre, comment on le retrouve et comment on le fait évoluer.
Une fiche produit qui change beaucoup de forme peut inviter à étudier un modèle documentaire. Un ensemble de commandes, de factures et de droits d'accès peut rendre un modèle relationnel très naturel. Ce sont des pistes de réflexion, pas des règles qui désignent automatiquement un gagnant.
Et « nous aurons un jour beaucoup de données » n'est pas encore une mesure de charge. Avant de préparer le site pour des millions d'utilisateurs imaginaires, regardons ce qui lui sera réellement demandé au lancement.
On peut utiliser l'un, l'autre ou les faire travailler ensemble. Les documentations de Next.js et de Symfony présentent leurs possibilités. Aucune ne dit que votre formulaire de devis a besoin de deux applications indépendantes.
Séparer une interface et un back-end peut être très utile. Mais cela peut aussi ajouter une API à gérer, plusieurs déploiements, des accès entre services et davantage de tests. Il faut que le bénéfice justifie cette organisation.
Imaginez que vous vouliez simplement modifier la question posée avant un rendez-vous. Si ce changement ordinaire demande l'intervention de trois spécialistes et le déploiement de plusieurs services, on doit pouvoir expliquer ce que cette complexité vous apporte en échange.
Une PWA peut apporter des capacités utiles à un service consulté régulièrement : installation, certaines fonctions hors connexion ou notifications, selon ce qui est développé et supporté. Ce ne sont pas des avantages automatiques obtenus en collant une étiquette sur le site.
Si vos clients reviennent chaque jour dans leur espace, l'intérêt mérite d'être étudié. S'ils viennent une fois lire vos horaires, un site mobile rapide et clair répond peut-être déjà au besoin. La question est l'usage, pas le prestige du sigle.
Je demanderais à un prestataire de prendre une modification ordinaire de votre activité et de raconter comment elle sera réalisée. Ajouter une prestation, changer une règle de réservation, récupérer les données : cela donne souvent une discussion plus utile que « quelle technologie est la plus performante ? ».
Il faut aussi parler de la sortie. Qu'est-ce que vous pourrez récupérer si la collaboration s'arrête ? Qui aura accès au domaine, aux données et aux services ? Une architecture peut être très élégante tout en vous rendant dépendant d'un outil ou d'une personne.
Chez Cadarsir, je pars de ce que le site doit permettre de faire, puis je choisis les briques et le périmètre. Une technologie spécialisée peut tout à fait être la bonne réponse lorsqu'elle règle un problème identifié. Elle n'a pas besoin d'être à la mode pour ça.
Votre entreprise doit pouvoir avancer grâce au site. Si l'architecture devient le sujet principal à chaque échange, alors qu'une demande simple attend toujours, on a probablement inversé les priorités.
Je ne suis pas contre les nouveaux outils. Un développeur a le droit d'aimer essayer des choses. Le problème commence quand son envie d'essayer devient votre facture, puis votre problème de maintenance pendant les années qui suivent.
Une stack, c'est l'ensemble des briques techniques d'un projet. On peut bien la choisir sans courir après chaque nouveau nom, et mal la choisir avec des technologies très connues. Le point de départ doit rester ce qu'il faut construire.
On ne compare pas un moteur, un coffre et une autoroute
MongoDB est une base de données. NoSQL désigne un ensemble de familles de bases, dont les bases orientées documents comme MongoDB. MySQL est une base relationnelle. Next.js est un framework autour de React pour construire des applications web ; Symfony est un framework PHP. Varnish intervient comme cache HTTP et reverse proxy. Une PWA concerne des capacités et une expérience applicative apportées par le web.Ces termes ne sont donc pas des réponses concurrentes à une seule question. Un projet peut combiner plusieurs de ces briques. Dire « on hésite entre MongoDB et une PWA » revient un peu à hésiter entre le coffre d'une voiture et sa manière de se conduire.
Vous n'avez pas à retenir tout le dictionnaire. Votre prestataire doit surtout pouvoir expliquer quelle responsabilité remplit chaque brique, et ce qui rend celle-ci nécessaire pour votre projet.
Les données ne deviennent pas simples parce que la base est flexible
Prenons une commande : elle appartient à un client, contient des produits, possède un montant et peut être liée à un paiement. On doit pouvoir retrouver ces relations et faire respecter les règles qui les accompagnent.Une base relationnelle comme MySQL se prête à une organisation en tables liées. C'est une manière souvent très lisible de représenter ce type d'activité. Avec MongoDB, on organise les données en documents, en choisissant ce qu'on regroupe et ce qu'on référence. Cette approche peut correspondre à d'autres formes de données et à leurs usages.
Ce n'est pas « des règles » contre « aucune règle ». MongoDB permet aussi de travailler avec des relations et des transactions. Sa documentation sur la modélisation et les transactions montre que le choix demande une vraie conception. La flexibilité n'enlève pas la nécessité de savoir ce qu'on enregistre, comment on le retrouve et comment on le fait évoluer.
Une fiche produit qui change beaucoup de forme peut inviter à étudier un modèle documentaire. Un ensemble de commandes, de factures et de droits d'accès peut rendre un modèle relationnel très naturel. Ce sont des pistes de réflexion, pas des règles qui désignent automatiquement un gagnant.
Et « nous aurons un jour beaucoup de données » n'est pas encore une mesure de charge. Avant de préparer le site pour des millions d'utilisateurs imaginaires, regardons ce qui lui sera réellement demandé au lancement.
Une interface moderne ne vous oblige pas à multiplier les applications
Next.js peut servir à construire une interface et ses mécanismes de rendu autour de React. Symfony peut porter une application structurée, ses traitements métier, ses formulaires et ses intégrations. Leur rôle exact dépend du projet ; Next.js ne se réduit pas au navigateur, et Symfony n'interdit pas les interfaces interactives.On peut utiliser l'un, l'autre ou les faire travailler ensemble. Les documentations de Next.js et de Symfony présentent leurs possibilités. Aucune ne dit que votre formulaire de devis a besoin de deux applications indépendantes.
Séparer une interface et un back-end peut être très utile. Mais cela peut aussi ajouter une API à gérer, plusieurs déploiements, des accès entre services et davantage de tests. Il faut que le bénéfice justifie cette organisation.
Imaginez que vous vouliez simplement modifier la question posée avant un rendez-vous. Si ce changement ordinaire demande l'intervention de trois spécialistes et le déploiement de plusieurs services, on doit pouvoir expliquer ce que cette complexité vous apporte en échange.
Un cache ou une PWA doivent résoudre quelque chose
Varnish peut éviter au serveur de refaire le même travail pour des réponses qui peuvent être partagées. C'est intéressant, mais il faut aussi savoir quand renouveler ce qui est en cache. Servir très vite un ancien tarif n'est pas le résultat recherché. J'explique le mécanisme dans l'article consacré à Varnish.Une PWA peut apporter des capacités utiles à un service consulté régulièrement : installation, certaines fonctions hors connexion ou notifications, selon ce qui est développé et supporté. Ce ne sont pas des avantages automatiques obtenus en collant une étiquette sur le site.
Si vos clients reviennent chaque jour dans leur espace, l'intérêt mérite d'être étudié. S'ils viennent une fois lire vos horaires, un site mobile rapide et clair répond peut-être déjà au besoin. La question est l'usage, pas le prestige du sigle.
Le devis ne montre pas encore les trois prochaines années
Les outils choisis influencent ce que vous allez payer après la livraison : hébergement, abonnements externes, mises à jour, surveillance et évolutions. Ils influencent aussi la facilité avec laquelle une autre personne pourra reprendre le travail.Je demanderais à un prestataire de prendre une modification ordinaire de votre activité et de raconter comment elle sera réalisée. Ajouter une prestation, changer une règle de réservation, récupérer les données : cela donne souvent une discussion plus utile que « quelle technologie est la plus performante ? ».
Il faut aussi parler de la sortie. Qu'est-ce que vous pourrez récupérer si la collaboration s'arrête ? Qui aura accès au domaine, aux données et aux services ? Une architecture peut être très élégante tout en vous rendant dépendant d'un outil ou d'une personne.
Je préfère une technologie qu'on sait faire vivre
Une base éprouvée a un intérêt concret : ses comportements sont mieux connus et il existe des outils, de la documentation et des compétences pour l'exploiter. Ce n'est pas une raison pour refuser toute nouveauté. C'est une raison pour ne pas traiter la nouveauté comme une preuve suffisante.Chez Cadarsir, je pars de ce que le site doit permettre de faire, puis je choisis les briques et le périmètre. Une technologie spécialisée peut tout à fait être la bonne réponse lorsqu'elle règle un problème identifié. Elle n'a pas besoin d'être à la mode pour ça.
Votre entreprise doit pouvoir avancer grâce au site. Si l'architecture devient le sujet principal à chaque échange, alors qu'une demande simple attend toujours, on a probablement inversé les priorités.
