Quand nous avons commencé à construire Odavio, nous avons pris une décision qui a fait sourciller : nous avons tout misé sur Cloudflare. Pas seulement pour l'hébergement ou le CDN, pour tout. Notre API tourne sur Workers. Notre base de données est D1 (SQLite en périphérie). Notre stockage de fichiers est R2. Notre messagerie en temps réel fonctionne sur les Durable Objects. Notre frontend se déploie sur Cloudflare Pages.
La plupart des gens pensaient qu'on était fous. « Vous construisez une plateforme d'affaires sur SQLite ? » Oui. Et nous le referions sans hésiter.
Notre cadre de décision
Nous avons évalué notre pile technologique selon trois critères :
- Simplicité opérationnelle — Nous sommes une petite équipe. Chaque pièce d'infrastructure que nous n'avons pas à gérer, c'est du temps pour le produit.
- Performance mondiale — Nos utilisateurs sont au Canada, aux États-Unis et en Europe. Ils méritent tous la même expérience rapide.
- Prévisibilité des coûts — Les factures cloud traditionnelles sont un cauchemar. Nous voulions un modèle où les coûts évoluent avec l'utilisation réelle.
Pourquoi Workers + D1
Les Cloudflare Workers s'exécutent en périphérie dans plus de 300 villes. Pas de problème de démarrage à froid comme avec Lambda. Pas de région à choisir. Votre code s'exécute simplement près de vos utilisateurs, partout.
D1, c'est SQLite répliqué mondialement. Pour un SaaS multi-locataire qui sert des petites entreprises, les requêtes sont simples et SQLite les gère très bien. Nous n'avons pas besoin de la complexité de Postgres pour ce que nous construisons.
Le résultat : nos réponses API se complètent généralement en moins de 50 ms pour les utilisateurs du monde entier.
Les Durable Objects pour le temps réel
La partie la plus sous-estimée de notre stack, ce sont les Durable Objects. Nous les utilisons pour notre système de messagerie en temps réel. Chaque conversation a son propre Durable Object, essentiellement un petit serveur à état qui vit en périphérie. Il gère les connexions WebSocket, l'ordre des messages et la détection de présence.
C'est élégant parce que nous n'avons pas à mettre en place Redis, à gérer des serveurs WebSocket, ou à nous inquiéter de la scalabilité horizontale. Cloudflare fait tout ça. Nous, on code la logique métier.
Les parties difficiles
Soyons honnêtes sur les défis :
- D1 est encore en maturation. Nous avons vite heurté des limites de lignes et avons dû repenser certains modèles de requêtes. Pas de recherche full-text native, donc nous avons construit la nôtre.
- Le débogage de systèmes distribués, c'est galère. Quand votre code tourne dans 300 villes, reproduire un bug qui ne se manifeste qu'à un endroit nécessite une bonne infrastructure de journalisation.
- L'écosystème est plus petit. Comparé à AWS, il y a moins d'articles de blog, moins de réponses Stack Overflow, moins de bibliothèques. Vous êtes parfois le premier à résoudre un problème particulier.
- L'enfermement fournisseur est bien réel. Notre code est profondément intégré aux API de Cloudflare. Migrer serait un gros effort. Nous avons accepté ce compromis parce que les avantages l'emportent sur les risques pour nous.
Les bénéfices inattendus
La vélocité de développement. Sans infrastructure à gérer, notre pipeline de déploiement, c'est juste « git push ». Pas de Terraform, pas de YAML Kubernetes, pas de Docker compose.
L'efficacité des coûts. Notre facture d'infrastructure mensuelle pour servir des milliers d'utilisateurs est inférieure à 50 $. Cela comprend la base de données, le stockage de fichiers, le compute Workers, et les Durable Objects.
La résilience. Nous n'avons jamais eu une panne que nous avons nous-mêmes causée. Pas de groupe de sécurité mal configuré, pas de base de données saturée, pas de conteneur qui crash. L'infrastructure gérée fonctionne, point.
Le referions-nous ?
Sans question. Pour notre cas d'usage, la pile Cloudflare est presque parfaite. Les contraintes de D1 nous ont forcés à écrire des requêtes plus simples et plus efficaces. Les limitations de Workers nous ont obligés à garder notre API légère. Ces contraintes ont amélioré notre produit.
Cela dit, cette stack n'est pas pour tout le monde. Si vous avez besoin de jointures SQL complexes sur des millions de lignes, ou de calcul GPU, ou si la diversité fournisseur est une exigence stricte, regardez ailleurs. Mais si vous construisez un produit SaaS moderne et que vous valorisez la simplicité, la performance et l'efficacité des coûts, Cloudflare mérite une sérieuse considération.