Une pile web pour les startups à l’ère des agents IA : Next.js, MUI et Firebase
Une pile web pour les startups de l’ère des agents de codage : Next.js, MUI, Firebase, Vercel et PostHog, avec une configuration minimale de l’agent et les raisons de chaque choix.
Sources: The Teach Stack for Building Full-Stack Apps in the AI-Agentic Era (2026 Edition)
Choisir une technologie lorsqu’un code est partiellement généré par machine
Des outils de codage tels que Claude Code et Codex ont changé la manière dont les logiciels sont développés. L’itération devient beaucoup plus rapide, ce qui est avantageux uniquement si le code reste suffisamment maintenable et scalable pour permettre au projet de continuer à évoluer.
Les startups en phase initiale dépendent de la vitesse d’itération. Les exigences changent rapidement, de nouvelles fonctionnalités sont ajoutées quotidiennement et le code est constamment réécrit. Dans de telles conditions, les technologies choisies doivent permettre des changements rapides sans détériorer l’expérience utilisateur.
La technologie présentée ci-dessous résulte d’environ quatre ans d’expérimentations avec des outils modernes sur une véritable plateforme d’apprentissage. Elle couvre l’authentification, l’interface utilisateur, le backend, l’hébergement, les tests et bien plus encore. L’objectif reste de développer rapidement sur une base de code que des humains peuvent encore maintenir, avec une infrastructure capable de s’adapter.
Réserver simplicité aux agents et au code
Les agents facilitent les améliorations rapides : les correctifs de bugs, les nouvelles fonctionnalités et les optimisations de performance arrivent tous rapidement. Ils facilitent également le sur-engineering, car ajouter des milliers de lignes de code est trivial. La discipline consiste à résister à la tentation de résoudre des problèmes qui n’existent pas encore et à maintenir le code, l’infrastructure et l’expérience utilisateur simples.
Une configuration simple et réduite est utile même à l’ère du développement par agents. Les agents coordonnent mieux, les fonctionnalités sont mises en production plus tôt, les bugs sont plus faciles à corriger, et les personnes peuvent toujours gérer ce qui existe déjà.
La démarche vis-à-vis des agents dans le code en production est équilibrée et la configuration reste modeste :
- Gardez
AGENTS.mdouCLAUDE.mdaussi courts que possible. Y inscrivez uniquement ce qui est répété dans chaque conversation, ainsi que les détails spécifiques au projet que les agents ont tendance à mal interpréter. - Des fichiers d’instructions trop volumineux peuvent nuire aux performances d’un modèle et en réduire l’utilité.
- Installez uniquement les compétences nécessaires à une conversation, puis supprimez-les à son terme.
- Moins de compétences et un fichier d’instructions plus petit fonctionnent généralement mieux que davantage.
- Certaines compétences sont utiles à avoir à disposition mais pas de manière permanente, car les conserver installées pollue la fenêtre de contexte. Les domaines utiles sont la conception UI/UX, React et Next.js, Firebase, ainsi que PostHog.
Sur les serveurs MCP, PostHog offre un accès facile aux traces d’erreurs et aux journaux, ce qui accélère le débogage. Context7 fournit à la modélisation une documentation de bibliothèques à jour, permettant aux agents de consulter les dernières informations relatives aux bibliothèques et aux frameworks. La plupart du temps, les agents résolvent les problèmes sans l’aide d’un serveur MCP, il est donc rarement nécessaire de les activer.
La règle générale est que chaque outil, compétence ou serveur supplémentaire concourt pour attirer l’attention du modèle. Tout ce qui ne se révèle pas utile pour la tâche en cours vaut mieux être exclu, et la configuration peut être revue chaque fois qu’une erreur récurrente apparaît et que des instructions simples suffiraient à la corriger.
Frontend : React et Next.js
React est le choix privilégié pour le cœur de nombreux projets full-stack. Vue et Svelte sont également des options, mais l’important écosystème de bibliothèques de React facilite l’ajout de fonctionnalités et les changements de direction, ce qui explique pourquoi les développeurs le préfèrent.
Le point faible réside dans les moteurs de recherche. Google et Bing utilisent des bots qui lisent l’HTML d’une page, et une page React commence généralement par un corps vide envoyé depuis le serveur. Pour que un site apparaisse dans les résultats de recherche, la première réponse du serveur doit contenir de l’HTML rempli des informations appropriées de la page.
Next.js s’occupe de cela. Il s’agit d’un framework React qui offre le rendu du côté serveur et la génération statique, de sorte que les pages sont d’abord rendues sur le serveur avant que l’HTML ne soit envoyé au navigateur. Ainsi, le contenu initial contient déjà tout ce dont ont besoin les bots. Par la suite, seul le JavaScript nécessaire est envoyé au client, ce qui permet de garder le fichier compact. L’expérience utilisateur ainsi que la compréhension par les outils de crawl se voient améliorées.
Le standard actuel dans les projets Next.js est le routeur app, qui rend faciles à utiliser des fonctionnalités comme la régénération statique incrémentale et le pré-rendu partiel, ce qui rend l’application plus rapide. Les nouveaux projets devraient commencer avec lui.
React évolue vers le côté serveur, se rapprochant ainsi quelque peu de PHP par son approche, et le routeur app offre une bonne expérience de développement pour les composants basés sur le serveur en premier. Le cache, Turbopack et une configuration adaptée aux agents accélèrent la création et l’itération des projets.
UI : une bibliothèque de composants au-dessus d’un design personnalisé
Le développement web traditionnel passe par la planification, la conception UI/UX, la mise en œuvre, ainsi que de nombreuses interactions entre les concepteurs et les développeurs. Les startups ne peuvent se permettre un cycle aussi long.
La méthode la plus efficace consiste à choisir un framework UI solide, MUI dans ce cas, et à suivre un modèle de conception. Une alternative consiste à faire dessiner tout par un concepteur dans Figma, puis à faire reconstituer le tout par des développeurs en utilisant React. Le fait de conserver une seule source de vérité dans le codebase a permis d’économiser des mois de travail.
MUI propose un ensemble riche de composants personnalisables répondant aux besoins courants. Tout peut être modifié, mais les paramètres par défaut sont suffisamment bons pour que la plupart des composants soient utilisés tels quels, avec leur comportement et leur apparence d’origine. Il inclut également une grande collection d’icônes pouvant être utilisées comme composants React, ce qui rend leur intégration très simple.
Il existe d’autres alternatives :
- shadcn/ui est moderne et populaire, bien que l’intégration du code de la bibliothèque dans son propre codebase via une CLI soit considérée par certains comme une pratique discutable.
- Ant Design est une excellente option.
- Chakra UI fonctionne également en tant que framework UI.
- HeroUI, anciennement NextUI, est aussi de bonne qualité.
Certaines personnes préfèrent styled-components ou Tailwind CSS. Avec l’un ou l’autre, il faut néanmoins écrire beaucoup de CSS, ce qui est moins avantageux en termes d’expérience de développement par rapport à un framework UI, surtout lorsque l’objectif est d’éviter de concevoir chaque page à partir de zéro.
Pour trouver de l’inspiration, les stores de templates sont utiles. Le store propre à MUI propose de nombreux templates UI attrayants, et Dribbble propose également des templates React. Une autre approche consiste à demander à un agence de créer plusieurs prototypes pour en choisir le meilleur ; posséder des compétences en UI/UX améliore la qualité des résultats obtenus.
Formulaires
Les formulaires représentent une grande partie du travail full-stack. Zod et React Hook Form s’associent bien et couvrent presque tout. Zod gère la validation des schémas, y compris les types, les plages, les longueurs et les enums, tandis que React Hook Form offre une API flexible pour interagir avec le formulaire. Ensemble, ils permettent des composants imbriqués partageant un même formulaire, des validations complexes ainsi que des mises à jour en temps réel des données. Les formulaires en deviennent presque trop simples.
Puisque le schéma de validation est un objet simple compatible TypeScript, les mêmes règles peuvent décrire ce que le formulaire accepte et ce que la fonction backend attend. Cela élimine toute possibilité de désaccord entre ce que l’interface utilisateur autorise et ce que le serveur rejette, et les agents peuvent lire un schéma de manière bien plus fiable que des logiques de validation dispersées dans des gestionnaires.
Backend, authentification et base de données
Firebase et Supabase proposent un backend en tant que service, capable de gérer des millions d’utilisateurs sans nécessiter de maintenance d’infrastructure propre. Cette solution utilise Firebase pour l’authentification, le stockage, la base de données Firestore ainsi que des fonctions serverless qui hébergent la logique backend personnalisée.
Authentification
Clerk est un outil performant pour l’authentification, mais le système par défaut de Firebase fonctionne tout à fait bien dans ce contexte. Firebase fournit également un package nommé firebaseui-web qui permet d’installer l’authentification sans avoir à écrire de code d’interface utilisateur. Pour que tout fonctionne correctement, l’application Next.js est également déployée sur un sous-domaine dédié à l’authentification, afin que Firebase puisse gérer les connexions sans problème.
Base de données
Dans une architecture traditionnelle, avec un frontend distinct et un backend gérant une base de données, le frontend déclenche de nombreuses appels API qui modifient les entrées de la base de données. Dans de nombreux projets, environ 80 % de ces appels correspondent à des opérations CRUD simples, tandis que les 20 % restants sont plus complexes, comme la mise à jour de plusieurs entrées ou l’agrégation de données provenant de plusieurs sources. Firebase est optimisé pour ces 80 %, ce qui permet de manipuler les données depuis le frontend sans avoir recours à des endpoints redondants.
Deux composants permettent cela.
- Règles Firestore. Le contrôle d’accès et les permissions sont regroupés dans un seul fichier,
firestore.rules. Les endpoints API n’ont pas besoin de vérifier les permissions dans chaque fonction, car Firebase vérifie automatiquement si un utilisateur peut lire une donnée ou la créer, la mettre à jour ou la supprimer. Cette séparation élimine une grande partie du code générique. - SDK client Firestore. La création, la lecture, la mise à jour et la suppression s’effectuent via le SDK Firebase, qui prend également en charge des écouteurs en temps réel, des incréments de compteur et des mises à jour par lots, le tout étant vérifié automatiquement contre
firestore.rules.
Il y a cependant une précaution à prendre concernant le modèle mental de stockage des données. Firestore est optimisé pour les lectures, qui constituent généralement la majorité des opérations, ce qui favorise l’utilisation de données dénormalisées. Cela peut sembler peu naturel pour ceux ayant une expérience en SQL, et une bonne conférence sur la modélisation des données Firestore vaut la peine d’être regardée.
Dans l’ensemble, Firestore offre une excellente expérience utilisateur, notamment grâce aux écouteurs de changements en temps réel, ainsi qu’une bonne expérience de développement, permettant à l’application de s’adapter rapidement aux besoins changeants.
Il est préférable de lancer de nouveaux projets sur l’édition Enterprise de Firestore en mode Native. Celle-ci prend en charge des fonctionnalités absentes de la version standard plus ancienne, telles que les requêtes en pipeline et une recherche plein texte intégrée, offrant ainsi la flexibilité d’une base de données similaire à MongoDB tout en conservant la facilité d’utilisation de Firestore.
Fonctions serverless
Le code client reste délibérément simple, les parties complexes étant isolées dans du code backend au sein des fonctions serverless. Ce principe consistant à garder le frontend simpliste et le backend sophistiqué s’est avéré très efficace. Les Firebase Functions peuvent contenir n’importe quel code backend, et ils peuvent être déclenchés par une simple demande HTTP, par la création ou la mise à jour d’une entrée Firestore, ou selon un calendrier prédéfini via Pub/Sub. Toutes les fonctionnalités côté serveur peuvent donc être regroupées dans des fonctions distinctes et autonomes.
Les outils BaaS tels que Firebase économisent beaucoup de temps et fonctionnent généralement sans problème. Le débogage de problèmes liés à des irrégularités dans la base de données ou à des migrations échouées est un phénomène rare.
Fonctionnalités d’IA
L’IA constitue une partie essentielle des applications web modernes, et de nombreux produits intègrent des chatbots et des agents. Le SDK d’IA de Vercel permet d’intégrer différents fournisseurs de modèles ainsi que de créer des agents personnalisés. Son avantage réside dans la facilité avec laquelle on peut ajouter des modèles différents et les alterner, offrant ainsi une expérience de développement plus simple que tout SDK spécifique à un modèle.
Tests
Le testage est probablement le sujet le plus controversé, en particulier pour les startups dont les exigences changent constamment. Au début, il n’y avait pas de tests. À mesure que le produit se développait, modifier le code existant en étant sûr que le système de production continuerait de fonctionner est devenu presque impossible, c’est pourquoi des tests ont été introduits pour le backend, plus précisément pour la couche de services de Firebase Functions. Le frontend n’est pas testé car il est conçu de manière simplifiée, tandis que le backend, plus complexe, est testé face à des cas limites.
Les tests backend utilisent Jest, avec faker.js pour générer des données fictives au sein des tests. Ils s’exécutent sur un projet Firebase distinct afin que la production reste inchangée, ce qui permet également des itérations rapides sans risque d’affecter les utilisateurs. Une fois les tests réussis, la nouvelle version de Functions est déployée en production.
La raison pour laquelle seuls les tests backend sont effectués tient aux coûts. Un frontend qui se contente d’afficher des données et d’appeler des fonctions ne présente que peu de logique méritant d’être vérifiée, et les tests UI ont tendance à échouer chaque fois que le design change, ce qui est constant dans un produit encore jeune. C’est dans la logique backend que des régressions silencieuses peuvent corrompre des données ou facturer à tort un utilisateur, c’est donc là que les efforts sont concentrés.
Refactoring
Au fur et à mesure que le projet grandit, les fonctionnalités changent, les exigences évoluent et les éléments vieillissent, le refactoring devient inévitable. Deux éléments contribuent le plus à modifier le code avec confiance : TypeScript et des tests d’intégration solides. TypeScript permet de préserver la sécurité des types après les modifications, tandis que les tests d’intégration confirment que la logique continue de fonctionner correctement.
Le refactoring survient plus souvent que prévu. Il n’y a pas eu de période de six mois sans une refonte majeure, car la plateforme continue de changer et l’adoption de nouvelles technologies entraîne de gros changements dans le code. Les deux étapes les plus importantes ont été le passage de React pur à Next.js, puis du routeur de pages de Next.js au routeur d’applications.
Hébergement
Comme le backend est entièrement basé sur Firebase (Google Cloud), le frontend est déployé sur Vercel, qui offre l’infrastructure la plus pratique pour déployer Next.js. Son intégration avec GitHub fonctionne bien avec les branches et ne nécessite aucune configuration manuelle :
- Une mise à jour vers
mainest déployée en production automatiquement. - Une mise à jour vers n’importe quelle autre branche déclenche un déploiement en version préliminaire avec son propre lien, permettant ainsi de visualiser chaque branche en temps réel, ce qui facilite et accélère l’itération.
Examiner un changement signifie donc ouvrir un lien sans télécharger de branche ni l’exécuter localement, ce qui convient à une petite équipe où les designers, les responsables produits et les ingénieurs souhaitent tous voir le travail en cours sans avoir à effectuer de configuration sur leurs propres machines.
Analyses et surveillance
Connaître l’identité des utilisateurs et la manière dont ils utilisent le produit est précieux. Cela peut économiser des semaines ou des mois de développement en indiquant ce qu’il convient de prioriser, et une bonne surveillance améliore l’expérience en mettant en évidence les bugs fréquents.
PostHog couvre ici les analyses générales et la surveillance du produit, y compris la relecture des sessions, la capture des exceptions, les journaux et les cartes sources en production. Google Analytics pour Firebase est une alternative gratuite qui nécessite plus de configuration, tandis que Sentry est un peu plus cher. Tous ces outils aident à mieux comprendre les utilisateurs, mais rien ne remplace le contact direct avec eux.
Le courriel reste l’un des moyens les plus fiables pour rester en contact avec les utilisateurs, envoyer des mises à jour et les maintenir engagés. Le stack a récemment été changé de Sendgrid à react-email en même temps que Resend.
react-email permet de créer des e-mails hautement personnalisables en transformant chacun d’eux en composant React. Resend s’intègre bien avec lui et propose de bons tarifs. Comme les e-mails sont des composants React, ils sont soumis au contrôle de version avec le reste du code, ce qui permet de suivre chaque modification en un seul endroit.
Prévisualiser et tester les modèles est tout aussi simple, car le même composant s’affiche dans le navigateur pendant le développement et génère l’HTML qui est envoyé dans les boîtes aux lettres.
Lectures complémentaires
- Un agent QuickBooks Finance fonctionnant avec un LLM local via Ollama et LangChain — Un agent ReAct sur Qwen 3.5 9B et une RTX 4070 qui lit en temps réel les données de QuickBooks sans aucun coût lié au cloud. Consultez le code, les résultats et les limites connues.
- Conception d’un outil de recherche d’emplois multi-agents : pipeline, HyDE et observabilité — Un pipeline LangGraph en neuf étapes qui met en correspondance les CV avec les offres d’emploi, avec huit choix de conception concernant HyDE, le routage des modèles, les limites de fréquence et le suivi des opérations.