Les conseils d’architecture vieillissent mal, alors soyons clairs : voici ce vers quoi j’irais aujourd’hui, pour le type de produits que je construis, et non une loi de la nature. Vos contraintes peuvent pointer ailleurs. C’est très bien.
Ennuyeux est une qualité
La propriété la plus sous-estimée d’une stack, c’est le nombre de surprises qu’elle vous épargne à 2h du matin. Je préfère livrer sur des outils un peu démodés et profondément compris que sur le framework le plus récent avec trois articles de blog et un Discord. Postgres plutôt que la base exotique. Un langage typé plutôt qu’un langage malin. Choisissez une technologie que vous savez déboguer quand elle casse, parce qu’elle cassera.
TypeScript de bout en bout
Partager les types entre le client et le serveur élimine toute une classe de bugs qui exigeaient des tests. Quand le contrat d’API est un type que les deux côtés importent, un changement cassant devient une erreur de compilation au lieu d’un 500 en production. Cette seule propriété m’a fait gagner plus de temps que n’importe quelle fonctionnalité de framework.
Je m’appuie là-dessus partout, y compris la couche de validation. Analysez les données entrantes en formes typées à la frontière et le reste de votre code peut leur faire confiance, ce qui est aussi un gain de sécurité discret, dans l’esprit de ma checklist de sécurité.
L’edge en vaut la peine, avec des limites
Exécuter du code près des utilisateurs, sur quelque chose comme Cloudflare Workers, fait une vraie différence de latence, et le modèle tarifaire est difficile à contredire. J’y héberge des sites statiques et de petites API sans souci. Ce portfolio même tourne sur cette configuration.
Le piège, c’est que l’edge n’est pas un serveur normal. Pas de connexions longues, des limites CPU serrées, un runtime différent. Excellent pour le requête-réponse et inadapté aux gros traitements en arrière-plan. Sachez quelle moitié de votre application va où, et n’essayez pas de tout forcer dans une seule boîte.
Le rendu : choisissez par page, pas par application
Le débat statique contre dynamique est surtout un faux choix. Une page marketing doit être statique et mise en cache à l’edge. Un tableau de bord doit être dynamique et personnalisé. Un blog peut être statique avec les données tirées au build, exactement la façon dont les articles que vous lisez sont publiés. Les frameworks modernes permettent de mélanger ça par route, alors utilisez-le au lieu de choisir une seule stratégie pour tout le site.
Où l’IA s’insère dans la stack
Si votre produit a une fonctionnalité IA, ce n’est qu’un service de plus dans votre architecture, avec les mêmes préoccupations que toute dépendance externe : latence, coût, gestion des pannes, et le fait que sa sortie ne se fait pas aveuglément confiance. Je garde le modèle derrière une API interne propre pour pouvoir changer de fournisseur, mettre en cache et ajouter des garde-fous au même endroit. Les détails d’ingénierie sont dans l’ingénierie IA pratique, et si la fonctionnalité implique des agents autonomes, les contraintes de sécurité de l’IA agentique en cybersécurité s’appliquent directement.
Ce que j’éviterais
Les microservices pour une équipe de trois. Vous passerez plus de temps sur le réseau entre services que sur le produit. Commencez par un monolithe bien organisé et ne le découpez que lorsqu’une partie précise a vraiment besoin de monter en charge seule.
Et résistez à adopter un outil parce qu’une grande entreprise l’utilise. Ses problèmes ne sont pas les vôtres. La bonne architecture pour la plupart des projets est plus petite et plus ennuyeuse que ne le suggèrent les conférences, et c’est généralement tout l’intérêt.
Laisser un commentaire