Cloud et DevOps pour les TPE/PME : une infrastructure scalable sans sur-ingénierie

La discussion sur l’infrastructure cloud part souvent du mauvais pied. Quelqu’un évoque "Kubernetes", un autre "les microservices", et une semaine plus tard, on se retrouve avec un diagramme à 17 boîtes que personne ne sait maintenir. Pendant ce temps, l’entreprise compte 50 clients et un serveur qui plante le lundi.

Parlons infrastructure réelle pour des entreprises réelles.

Le piège de la pré-optimisation

Donald Knuth l’a dit dans les années 70 et ça reste vrai : optimiser trop tôt est la racine de tous les maux en développement logiciel. Avec l’infrastructure, c’est encore pire, car on paie aussi pour ça chaque mois. Toute capacité provisionnée sans réelle nécessité, c’est de l’argent dépensé pour rien et impossible à récupérer.

La bonne question au démarrage n’est pas : « Comment vais-je scaler à un million d’utilisateurs ? » mais plutôt : « Comment puis-je éviter de planter avec les 100 premiers utilisateurs, et comment puis-je m’assurer que le scaling à un million sera possible le moment venu, sans tout réécrire ? »

Ce dont une TPE/PME a vraiment besoin

D’après les projets que nous avons menés, la stack que nous utilisons dans la grande majorité des cas est plutôt… ennuyeuse (au sens positif du terme) :

• Frontend et serveur de rendu côté serveur : Vercel pour le déploiement, avec Next.js. La raison est simple : zéro configuration pour démarrer, scaling automatique, edge en Amérique latine, et un coût qui commence à 0 USD jusqu’à un certain volume.
• Base de données et backend basique : Supabase. Postgres solide avec une interface intuitive, auth incluse, storage, et une sécurité au niveau des lignes pour les applications multi-locataires. C’est la solution la plus proche de « Firebase, mais avec SQL ».
• Stockage de fichiers lourds : Cloudinary ou S3 direct, selon les besoins.
• Observabilité minimale : Vercel Analytics + Sentry pour les erreurs. Datadog et sa suite viendront plus tard.
• CI/CD : GitHub Actions. Gratuit jusqu’à des volumes que 95 % des TPE/PME ne dépasseront jamais.

C’est tout. Aucun cluster Kubernetes, aucune maille de services, aucun contrôleur d’ingress. Et pourtant, ça tient des centaines de milliers de requêtes sans broncher.

Le cas Tontin : quand il faut complexifier

Il existe des moments où une infrastructure simple ne suffit plus. Tontin, notre plateforme de coaching par IA, en est un exemple. Ici, on rencontre des problèmes que Vercel + Supabase ne résolvent pas seuls :

• Appels à plusieurs fournisseurs d’IA avec basculement automatique en cas d’échec (Groq, Gemini, OpenAI, Anthropic). Cela nécessite une couche d’orchestration dédiée.
• Recherche sémantique avec embeddings. Résolue avec pgvector intégrée directement dans le Postgres de Supabase, évitant ainsi d’ajouter Pinecone ou Weaviate et simplifiant l’infrastructure.
• Compression de contexte entre les sessions pour conserver une mémoire persistante sans exploser les coûts de tokens. Une couche intermédiaire développée en TypeScript réduit le contexte de 50 % avant chaque appel.
• Plus de 500 conversations complètes servies par cette architecture sans temps d’arrêt.

Le point crucial : la complexité s’ajoute quand le métier en a besoin, pas quand le diagramme commence à ressembler à une œuvre d’art.

Quand passer à Kubernetes (la réponse est : presque jamais, pour l’instant)

La règle opérationnelle est simple : si vous ne savez pas avec certitude pourquoi Kubernetes est nécessaire, alors vous n’en avez pas besoin. Les rares raisons légitimes :

• Vous gérez plus de 10 services indépendants mis à jour à des rythmes différents.
• Votre volume de trafic justifie plusieurs nœuds et une orchestration (on parle ici de milliers de requêtes par seconde en continu).
• Votre équipe DevOps a une expérience avérée dans l’exploitation de clusters. C’est le point le plus important : un Kubernetes mal géré est pire qu’un serveur monolithique bien entretenu.

Pour une TPE/PME typique avec 1 à 3 produits et un trafic mesurable en centaines de requêtes par minute, Vercel + Supabase + quelques services serverless couvrent tout, à une fraction du coût, et peuvent être maintenus par un seul développeur.

Observabilité : le minimum syndical que vous ne pouvez pas ignorer

Il y a trois choses absolument indispensables à mettre en place dès le premier jour, même si le reste de l’infrastructure reste minimaliste :

1. Des logs accessibles. Si vous ne pouvez pas voir ce qui s’est passé quand un problème survient, vous êtes dans le noir. Vercel et Supabase les incluent nativement.
2. Des alertes pour les erreurs critiques. Sentry gratuit couvre la majorité des cas. La règle : si une erreur impacte un utilisateur en production, quelqu’un doit en être informé dans les 5 minutes.
3. Des métriques d’usage. Nombre d’utilisateurs actifs, pages visitées, taux de conversion. GA4 + Vercel Analytics. Sans cela, toute décision d’optimisation relève de la pure intuition.

La règle d’or

On commence simple. On mesure. Quand quelque chose ne scale pas, on optimise. Quand quelque chose plante trop souvent, on refactorise. Mais on n’ajoute pas de complexité par anticipation. Chaque boîte supplémentaire dans le diagramme, c’est une boîte de plus qui peut tomber en panne, et une ligne de plus dans la facture AWS.

Si vous lancez une nouvelle infrastructure ou que vous avez déjà un système qui plante quand il ne le devrait pas, contactez-nous. Nous auditons votre setup actuel et vous indiquons où vous payez trop cher ou où se cache un risque insoupçonné.

---

Par Esteban Aleart, Fondateur & Lead Engineer chez Pair Programming.