Quand on shippe seul, le piège DevOps numéro un consiste à imiter la stack d’une équipe de cinquante. Le devops solo développeur qui enrôle Kubernetes, Terraform multi-cloud et un stack d’observabilité à six tiers passe ses week-ends à maintenir l’outillage au lieu d’expédier des features. La cible 2026 est plus modeste et plus efficace : quatre piliers (CI/CD, hosting, observabilité minimale, backups), des coûts mensuels chiffrés sous 50 € pour un freelance ou indie hacker actif, et une brique LLM locale via Ollama pour générer scripts, docs et messages de commit hors ligne. Cet article propose la stack qu’on monte en deux jours et qu’on garde trois ans.
DevOps solo en 2026 : 4 piliers, c’est tout
DevOps (Development + Operations, raccourci désignant la culture et l’outillage qui rapprochent le code de la production) se résume pour un solo à quatre besoins concrets, hiérarchisés par criticité.
CI / CD
CI (Continuous Integration) lance les tests à chaque push. CD (Continuous Deployment) pousse en production le code qui passe. Sans ces deux, vous oubliez de tester avant de déployer, vous déployez à la main, vous cassez en prod un vendredi soir. La règle minimum : tout merge sur main exécute lint, tests et build automatiquement, et un déploiement réussi suit en moins de 5 minutes.
Hosting et déploiement
L’hébergement plateforme (Fly.io, Railway, Render) remplace avantageusement le couple AWS + Terraform pour un solo. Vous décrivez votre app dans un fichier de config, vous poussez, c’est en ligne. Pas de VPC, pas d’IAM à gérer, pas de cluster à patcher. Le rendement par heure travaillée n’est pas comparable.
Observabilité (logs + erreurs)
Logs structurés en JSON, capture des erreurs runtime, alerte email ou Slack quand quelque chose casse. Pas besoin de Datadog ni de Grafana hébergé : Sentry pour les erreurs et les logs natifs de la plateforme suffisent dans 95 % des cas. Vous ajouterez plus tard si le besoin s’impose.
Backups et incidents
Un dump quotidien de la base, copié hors plateforme, et un runbook d’incident de 10 lignes. Statistiquement, 90 % des restaurations sur projet solo se font moins de 24 heures après la perte. Un backup quotidien suffit donc largement, à condition qu’il soit testé une fois par trimestre.
La stack qu’on recommande en 2026
GitHub Actions pour la CI
Gratuit jusqu’à 2 000 minutes par mois sur les repos privés, illimité sur les repos publics. Voici un workflow complet build + test + deploy qui couvre 80 % des besoins.
name: ci-cd
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint
- run: npm test -- --coverage
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
concurrency: production
steps:
- uses: actions/checkout@v4
- uses: superfly/flyctl-actions/setup-flyctl@master
- run: flyctl deploy --remote-only
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}La doc GitHub Actions couvre l’essentiel. Pour les workflows multi-environnements, ajoutez un job deploy-staging sur la branche develop et basculez via environment.
Fly.io / Railway / Render pour le déploiement
Trois plateformes solides pour un solo, avec des positionnements différents.
| Plateforme | Sweet spot | Tarif d’entrée | Limite à connaître |
|---|---|---|---|
| Fly.io | App à plusieurs régions, Postgres managé | ~5 €/mois machine + DB | Configuration fly.toml à apprendre |
| Railway | Prototype rapide, services multiples | 5 $/mois pack incluant crédit | Coûts qui grimpent avec le trafic |
| Render | App classique + services managés | 7 $/mois service web + DB | Cold start sur le tier gratuit |
Fly.io tient notre préférence pour les projets qui visent une présence multi-régions ou un Postgres performant. Railway gagne sur le temps de cadrage initial. Render reste un excellent compromis pour qui aime l’interface web propre. La doc Fly.io couvre tous les cas standards.
Sentry / Highlight pour les erreurs
Sentry reste l’outil de référence en 2026 : tier gratuit généreux (5 000 erreurs par mois), SDK pour quasiment toutes les plateformes, intégration Slack et GitHub native. Branchez-le dès le premier déploiement, configurez l’environnement (production, staging) et la release via la variable SENTRY_RELEASE du workflow CI. Highlight (open source, hébergeable) est une alternative pertinente pour qui veut garder ses données chez soi. Voir la doc Sentry.
Hetzner / Neon / Supabase pour la DB
Trois options selon le profil. Hetzner Cloud à 4 €/mois pour un VPS qui tient une instance Postgres autonome (avec pg_dump en cron). Neon pour Postgres serverless avec branches façon Git, idéal en environnements éphémères. Supabase si vous voulez l’auth, le storage et les RLS prêts à l’emploi avec votre Postgres.
Ollama en local pour la génération de code, de docs et de scripts ops offline
Ollama est l’utilitaire qui fait tourner des LLM en local sur votre machine, sans dépendance cloud. Pour un dev solo, il ne s’agit pas d’un effet de mode mais d’une brique d’efficacité concrète. Trois cas d’usage récurrents :
- Génération de scripts ops : un Dockerfile, un compose, un script de migration, un wrapper bash. Les modèles 7-14B locaux suffisent largement et tournent sur un MacBook M-series ou un PC avec 16 Go de RAM.
- Documentation Markdown : README, guide de déploiement, runbook d’incident, changelog. Le LLM rédige un premier jet, vous relisez et corrigez. 70 % de gain sur cette tâche peu palpitante.
- Audit ponctuel hors ligne : avion, bureau client sans wifi corporate, données sensibles que vous ne voulez pas envoyer dans un cloud LLM. Ollama règle le problème.
Pour les détails d’installation et de workflow, voyez notre guide dédié brique LLM locale Ollama dans la stack. Pour aller plus loin avec une chaîne d’outils 100 % locale (modèle, IDE, agent), voyez la stack IA dev 100% locale (pilier).
Ce qu’on peut différer (sans culpabiliser)
- Kubernetes : aucune raison sérieuse avant 5 services en parallèle ou 10 000 utilisateurs simultanés. Avant, c’est de l’over-engineering qui coûte vos week-ends.
- Terraform / OpenTofu : utile au-dessus de 3 environnements et 20 ressources cloud. Sous ce volume, un README + scripts shell font le job.
- Multi-cloud : un cloud bien maîtrisé bat trois clouds mal exploités. Choisissez un fournisseur, restez-y trois ans.
- Observabilité avancée (Datadog, New Relic) : 100 à 300 € par mois, justifié au-dessus de 10 microservices. Sous, Sentry + logs plateforme couvrent tout.
- SLOs formels : intéressant à partir de 5 personnes dans l’équipe, pas avant.
La règle de pragmatisme indie : ajouter un outil seulement quand l’absence d’outil coûte plus cher que l’outil lui-même.
Coûts mensuels réalistes pour 1 dev / 1-3 projets
Voici trois profils de dépenses observées sur des stacks réelles en 2026.
| Brique | Démarrage (1 projet) | Croissance (2-3 projets) | Confort (3 projets actifs) |
|---|---|---|---|
| GitHub Actions | 0 € | 0 € | 4 € |
| Hosting (Fly / Railway / Render) | 5 € | 15 € | 30 € |
| Base de données managée | 0 € (gratuit Neon/Supabase) | 10 € | 20 € |
| Sentry | 0 € | 0 € | 26 € |
| Domaines + emails | 3 € | 5 € | 10 € |
| Backups externes (Backblaze B2) | 1 € | 2 € | 5 € |
| Ollama (local) | 0 € | 0 € | 0 € |
| Total | ~9 €/mois | ~32 €/mois | ~95 €/mois |
On reste donc sous 100 € par mois pour trois projets actifs avec une stack honnête. À comparer à un AWS multi-services mal calibré qui flirte facilement avec 500 €.
Le runbook minimal en cas d’incident
Quand le site tombe, vous avez 10 secondes avant la panique. Un runbook court et accessible épargne ces 10 secondes.
- Vérifier le statut plateforme (Fly status, Railway status). Si outage upstream, attendre.
- Lire les 50 dernières lignes de logs :
flyctl logs -a votre-app. - Consulter Sentry : nouvelle erreur en pic ? Lien direct vers le commit fautif.
- Si déploiement récent :
flyctl releases rollbacksur la version précédente. - Si DB : vérifier disque, CPU, connexions. Restart si pression connexions.
- Communiquer aux utilisateurs (status page ou tweet pinned) sous 15 minutes.
- Postmortem écrit dans les 48 heures : cause, correction, prévention.
Cette stack se complète bien avec une posture sécurité de base — voir notre lecture OWASP Top 10 2026 — et un soin particulier sur la qualité du code généré, détaillé dans auditer le code généré par IA. Côté performance applicative, le pilier Core Web Vitals 2026 (pilier dev-moderne) donne le cadre de mesure.
Questions fréquentes
Quelle stack DevOps pour un développeur solo en 2026 ?
Le combo qui tient : GitHub Actions pour la CI, Fly.io ou Railway pour le hosting, Sentry pour les erreurs, Neon ou Supabase pour la base de données managée, Backblaze B2 pour les backups externes. Total sous 30 € par mois pour deux projets actifs, montage en deux jours. Ollama local en option pour générer scripts et docs hors ligne.
Faut-il Kubernetes quand on est seul ?
Non, presque jamais. Kubernetes apporte une valeur à partir de plusieurs services en parallèle, des équipes multiples, et un trafic significatif. Pour un freelance ou indie hacker avec un à trois projets, les plateformes-as-a-service comme Fly.io ou Railway font le même travail avec un dixième du temps de maintenance. Ne payez pas le prix de la complexité avant d’en avoir le besoin.
Combien coûte une stack DevOps solo par mois ?
Comptez 9 € par mois pour démarrer (un projet en production), 30 à 35 € en croissance (deux ou trois projets), et environ 95 € en confort soutenu (trois projets actifs avec Sentry payant et observabilité étendue). Bien en dessous d’un AWS multi-services classique et largement amorti par le temps économisé sur la maintenance.
Fly.io, Railway ou Render : que choisir en 2026 ?
Fly.io pour un déploiement multi-régions et un Postgres managé performant. Railway pour la rapidité de cadrage initial et les apps simples. Render pour qui cherche une interface très propre et des services managés clé en main. Aucune mauvaise réponse parmi les trois ; le choix dépend de vos préférences ergonomiques et du sweet spot de chaque plateforme.
Comment intégrer Ollama dans une stack DevOps solo ?
Ollama tourne en local et ne fait pas partie de la stack runtime de production. Vous l’utilisez côté développeur pour générer Dockerfile, scripts shell, README, runbooks d’incident, ou pour auditer du code en mode hors ligne. C’est une brique d’efficacité, pas un service à exposer. Installez-le, téléchargez un modèle 7-14B, branchez-le dans votre éditeur ou en ligne de commande, et utilisez-le sur les tâches répétitives qui sortent du chemin critique.
Stack DevOps solo à monter ou à nettoyer ? Nous pouvons la cadrer en une demi-journée, livrer le workflow GitHub Actions, le fichier de déploiement et le runbook d’incident. Présentez-nous votre contexte via le formulaire de contact.
