Devenir DevOps freelance : missions, compétences et TJM en 2026

Tu ouvres Slack à 8h17. Le canal production clignote déjà. Un déploiement a échoué cette nuit, l’équipe back ne sait pas si le rollback est propre, le CTO demande “qui peut regarder vite fait ?”, et l’ESN te propose justement une mission DevOps freelance de 6 mois.

Sur le papier, c’est tentant. Le marché cherche des profils capables d’automatiser les déploiements, fiabiliser le cloud, industrialiser Terraform, maintenir Kubernetes et remettre de l’ordre dans l’observabilité. Dans la pratique, le mot “DevOps” peut aussi cacher une mission fourre-tout où tu deviens l’astreinte humaine de toute la production.

Si tu viens du développement, de l’administration système, du cloud ou du support infrastructure, devenir DevOps freelance peut être une excellente trajectoire en 2026. À condition de vendre le bon périmètre, de fixer un TJM cohérent et de cadrer les responsabilités avant d’obtenir les accès production.

Dans ce guide, on va clarifier les missions DevOps, les différences avec SRE, Cloud Ops, Platform Engineer, SysOps et DevSecOps, les compétences à renforcer, les tarifs réalistes et la méthode pour te positionner en 90 jours.

1. Comprendre ce que vend un DevOps freelance

Un DevOps freelance aide une équipe à livrer du logiciel plus vite, plus proprement et avec moins de risques en production.

Dit autrement, tu ne vends pas “du Jenkins” ou “du Kubernetes”. Tu vends une chaîne de livraison fiable : code, tests, build, déploiement, infrastructure, monitoring, alertes, rollback et documentation.

Les briques du métier

Une mission DevOps couvre souvent plusieurs sujets :

• CI/CD : automatiser les builds, les tests, les déploiements et les rollbacks ;
• cloud : administrer AWS, Azure ou GCP avec des règles propres de réseau, sécurité, coûts et permissions ;
• infrastructure as code : décrire l’infrastructure avec Terraform, OpenTofu, Pulumi ou CloudFormation ;
• configuration management : standardiser les serveurs avec Ansible ou des outils équivalents ;
• conteneurs : construire, sécuriser et déployer des images Docker ;
• orchestration : exploiter Kubernetes, Helm, Argo CD ou Flux quand le contexte le justifie ;
• observabilité : métriques, logs, traces, alertes, dashboards et postmortems ;
• fiabilité : réduire les incidents, améliorer les temps de restauration et documenter les procédures ;
• sécurité : gérer les secrets, les droits, les scans d’images, les politiques réseau et les accès production.

Un bon DevOps freelance ne rend pas une équipe dépendante de lui. Il laisse une plateforme plus lisible, plus automatisée et plus facile à maintenir.

Ce point change ton positionnement. Si tu te présentes comme “celui qui règle les problèmes”, tu attires les urgences. Si tu te présentes comme “celui qui réduit les urgences”, tu vends une mission plus stratégique.

DevOps, SRE, Cloud Ops, Platform Engineer : comment choisir ton angle ?

Le marché mélange souvent les intitulés. Pour prospecter, tu dois savoir ce que tu veux vendre.

Positionnement	Ce que tu vends	Mission typique
DevOps freelance	Automatisation de la livraison et de l’infrastructure	CI/CD, Terraform, conteneurs, déploiements
SRE freelance	Fiabilité, disponibilité, incidents et SLO	observabilité, alerting, postmortems, résilience
Cloud Ops freelance	Exploitation cloud au quotidien	comptes cloud, réseau, sauvegardes, supervision
Platform Engineer	Plateforme interne pour les équipes produit	templates, self-service, golden paths, developer experience
SysOps	Administration système et exploitation infra	Linux, patching, sauvegardes, ordonnancement, MCO
DevSecOps	Sécurité intégrée dans le delivery	secrets, scans, policies, IAM, durcissement CI/CD

Tu peux combiner deux angles, mais évite de tout afficher au même niveau. “DevOps AWS Terraform Kubernetes avec culture SRE” est plus lisible que “DevOps, SRE, Cloud, Cyber, FinOps, Data, Full-stack”.

Si ton angle touche à la sécurité, complète avec le guide consultant cybersécurité freelance. Si ton angle touche aux coûts cloud, lis aussi le guide consultant FinOps freelance. Les trois métiers se croisent souvent, mais ils ne vendent pas la même décision.

2. Choisir les missions DevOps que tu veux vendre

Le piège du DevOps freelance, c’est l’annonce trop large : “recherche DevOps pour accompagner l’équipe”. Derrière, il peut y avoir une mission passionnante ou un poste salarié déguisé avec des tickets support sans fin.

Avant de répondre, cherche le livrable.

Audit CI/CD

Tu analyses les pipelines existants, les temps de build, les tests bloquants, les secrets exposés, les étapes manuelles et les déploiements fragiles.

Livrables possibles :

• cartographie des pipelines ;
• liste des risques et irritants ;
• plan d’amélioration priorisé ;
• refonte d’un pipeline modèle ;
• documentation de rollback.

C’est une bonne porte d’entrée si tu viens du développement. Tu parles le langage des équipes produit, et tu peux montrer vite des gains mesurables : temps de build réduit, erreurs de déploiement en baisse, meilleure visibilité.

Industrialisation Terraform

Beaucoup d’entreprises ont commencé Terraform par urgence. Trois ans plus tard, les modules sont dupliqués, les states sont mal séparés, les droits sont trop larges et personne n’ose modifier l’infrastructure.

Ton rôle peut être de remettre de l’ordre :

• séparation des environnements ;
• modules réutilisables ;
• conventions de nommage ;
• remote state sécurisé ;
• workflows de review ;
• plan de migration sans interruption ;
• documentation d’exploitation.

Terraform se vend très bien quand tu ne promets pas seulement de créer des ressources, mais de rendre l’infrastructure gouvernable.

Kubernetes et plateforme applicative

Kubernetes attire des TJM élevés, mais il attire aussi des contextes instables. Avant d’accepter, vérifie si le client a besoin de Kubernetes ou s’il a surtout besoin de livrer plus simplement.

Missions possibles :

• audit d’un cluster existant ;
• amélioration des déploiements Helm ;
• mise en place GitOps avec Argo CD ou Flux ;
• sécurisation des namespaces et RBAC ;
• monitoring Prometheus, Grafana, Alertmanager ;
• stratégie de montée de version ;
• runbooks d’incident ;
• accompagnement des développeurs.

Un profil Kubernetes senior peut monter haut en TJM. Mais si le client attend que tu sois disponible à chaque crash de pod sans cadrage, le tarif ne compensera pas l’usure.

Observabilité et résilience

L’observabilité devient un sujet central parce que les architectures se fragmentent : microservices, workers, files de messages, serverless, services managés, clusters, jobs data.

Tu peux vendre :

• instrumentation métriques, logs et traces ;
• dashboards par service et par équipe ;
• alertes moins bruyantes ;
• SLO et indicateurs de disponibilité ;
• postmortems anonymisés ;
• tests de restauration ;
• amélioration du temps moyen de résolution.

Le SRE commence souvent ici. On ne cherche pas seulement à savoir si “ça marche”. On cherche à comprendre ce qui casse, à quelle fréquence, avec quel impact et comment l’équipe réagit.

MCO et support production

Le maintien en conditions opérationnelles peut être rentable, surtout sur des missions longues. Mais il doit être contractuel.

Demande toujours :

• quels horaires sont inclus ;
• quelle astreinte est attendue ;
• quels niveaux de priorité existent ;
• quel délai de réponse est demandé ;
• qui décide en cas d’incident ;
• qui valide les changements ;
• quelle documentation existe ;
• combien de temps est réservé à l’amélioration continue.

Sans ces réponses, tu risques de vendre une mission DevOps et d’acheter une charge mentale permanente.

Build, run et ratio acceptable

Avant d’accepter une mission, demande la répartition entre build et run. C’est une question simple, mais elle révèle beaucoup.

Le build correspond aux chantiers de fond : refonte CI/CD, migration Terraform, mise en place GitOps, observabilité, automatisation, documentation, sécurisation des accès. Le run correspond à l’exploitation quotidienne : incidents, tickets, redémarrages, surveillance, demandes urgentes, support aux équipes.

Une mission DevOps peut très bien contenir du run. Le problème apparaît quand le run mange tout le reste. Sur Free-Work, certaines missions SRE récentes annoncent explicitement une répartition comme 60 % build et 40 % run, avec Kubernetes, Terraform, GitHub Actions, observabilité et gestion d’incidents. C’est le type de détail que tu dois obtenir avant de parler disponibilité.

Si le client ne sait pas dire quelle part de la mission sert à améliorer la plateforme, tu risques de maintenir le désordre au lieu de le réduire.

Repère les signaux d’alerte :

• “il y aura quelques tickets en plus” sans volume ;
• “on cherche quelqu’un d’autonome” sans backlog priorisé ;
• “il faut être réactif” sans horaires ni astreinte ;
• “tu reprendras l’existant” sans documentation ;
• “la priorité, c’est que la prod tienne” sans chantier de fiabilisation.

Un bon cadrage peut être très simple : 3 jours par semaine sur les chantiers d’amélioration, 1 jour sur le support N3, 1 demi-journée sur la documentation et les rituels d’équipe. Tu n’as pas besoin d’un modèle parfait. Tu as besoin d’un équilibre écrit.

3. Construire le socle technique attendu en 2026

Les recherches de missions DevOps, Cloud Ops et SRE publiées en 2026 font revenir les mêmes mots-clés : Terraform, Ansible, GitLab CI/CD, GitHub Actions, AWS, Azure, Kubernetes, Docker, Linux, monitoring, scripting et sécurité. Les offres cadres visibles sur l’Apec autour de DevOps et Kubernetes confirment aussi ce socle : pipelines CI/CD, automatisation, cloud, conteneurs et maintien des environnements.

Free-Work affiche par exemple des missions DevOps cloud récentes autour de ces stacks, avec des offres incluant Cloud Ops, Terraform et Kubernetes. Malt signale de son côté, dans ses Tech Trends 2026 Cloud & Infra, une hausse de 29 % de la demande Cloud Engineer, portée notamment par les workloads IA et les besoins d’infrastructure.

Les fondamentaux à maîtriser

Tu peux avoir une spécialité, mais tu dois garder un socle large.

Compétence	Niveau attendu en mission
Linux	services, logs, permissions, systemd, réseau, troubleshooting
Réseau	DNS, HTTP, TLS, routage, firewalling, load balancing, VPN
Git	branches, merge requests, tags, workflows de release
Docker	images, layers, registry, variables, volumes, sécurité de base
CI/CD	GitLab CI, GitHub Actions, Jenkins ou Azure DevOps
IaC	Terraform ou OpenTofu, modules, state, plan, import, drift
Cloud	au moins AWS, Azure ou GCP en production
Kubernetes	pods, deployments, services, ingress, RBAC, Helm, logs
Observabilité	Prometheus, Grafana, ELK/OpenSearch, Datadog, New Relic ou équivalent
Scripting	Bash et Python pour automatiser sans sur-ingénierie

Tu n’as pas besoin d’être expert sur chaque outil. En revanche, tu dois comprendre les interactions. Un incident “Kubernetes” peut venir d’un DNS, d’un certificat expiré, d’une limite CPU, d’un secret mal monté ou d’un réseau cloud mal configuré.

La stack à choisir pour te lancer

Si tu pars de zéro en freelance, ne tente pas de couvrir toutes les stacks du marché.

Choisis une combinaison vendable :

• AWS + Terraform + GitLab CI + Docker pour les PME cloud et scale-ups ;
• Azure + Terraform + Azure DevOps pour les grands comptes Microsoft ;
• Kubernetes + Helm + Argo CD + Prometheus pour les équipes platform ;
• Ansible + Linux + supervision pour des contextes plus infrastructure et MCO ;
• GitHub Actions + Terraform + cloud managé pour des éditeurs SaaS plus légers.

Le bon choix dépend de ton historique. Si tu as trois ans d’AWS en production, ne repars pas sur Azure juste parce qu’une étude dit que le marché le demande. Vends d’abord ce que tu sais défendre en entretien technique.

Les certifications utiles

Les certifications ne remplacent pas l’expérience, mais elles rassurent les acheteurs, surtout via ESN ou grands comptes.

Certifications pertinentes :

• AWS Solutions Architect Associate ou Professional ;
• AWS SysOps Administrator ;
• Microsoft Azure Administrator ou Azure Solutions Architect ;
• Google Professional Cloud DevOps Engineer ;
• Certified Kubernetes Administrator ;
• HashiCorp Terraform Associate ;
• GitLab Certified CI/CD Specialist ;
• certifications sécurité cloud si tu vises le DevSecOps.

Une certification aide à passer les filtres. Une preuve technique aide à signer.

Pour financer une montée en compétences, regarde aussi le guide formation freelance : CPF, financements et stratégies. Selon ton statut et ton activité, tu peux parfois faire prendre en charge une partie du coût.

4. Faire monter ton TJM avec les compétences non techniques

À stack égale, deux DevOps peuvent avoir 200 € d’écart de TJM. La différence vient souvent de la posture.

Communication avec les développeurs

Un DevOps freelance travaille rarement seul. Il doit embarquer des développeurs qui ont déjà des deadlines, des habitudes et parfois une méfiance envers “l’infra”.

Ce qui fait la différence :

• expliquer pourquoi une règle existe ;
• proposer des templates plutôt que des interdictions ;
• réduire la friction dans les pipelines ;
• documenter les erreurs fréquentes ;
• aider une équipe à devenir autonome.

Quand une équipe produit te voit comme un accélérateur, ton tarif devient plus facile à défendre.

Gestion d’incident

En incident, la technique ne suffit pas. Il faut garder un canal clair, hiérarchiser les hypothèses, éviter les modifications désordonnées et noter les actions.

Les clients paient cher un profil capable de :

• calmer la situation sans minimiser l’impact ;
• organiser un diagnostic ;
• séparer symptômes et causes ;
• communiquer avec un CTO ou un responsable métier ;
• documenter un postmortem sans chercher un coupable.

J’ai vu des missions se renouveler pour une raison simple : le freelance n’était pas seulement compétent en production, il rendait les incidents moins chaotiques pour tout le monde.

Documentation et transfert

La documentation est souvent le parent pauvre du DevOps. C’est aussi une opportunité.

Livrables qui augmentent ta valeur :

• runbook de déploiement ;
• procédure de rollback ;
• guide d’accès production ;
• matrice des droits ;
• schéma d’architecture ;
• checklist de mise en production ;
• postmortem anonymisé ;
• guide de reprise après incident.

Ce que tu documentes devient un actif pour le client. Ce que tu gardes dans ta tête devient une dépendance risquée.

Arbitrage risque, coût et vitesse

Le DevOps senior sait dire : “on peut le faire, mais voici le risque”.

Ce n’est pas une posture défensive. C’est une compétence business. Un rollback automatisé coûte du temps. Une architecture multi-zone coûte plus cher. Une astreinte 24/7 coûte de l’organisation. Une pipeline plus stricte ralentit parfois une équipe pendant deux semaines avant de la rendre plus fiable.

Le client ne veut pas toujours l’option la plus robuste. Il veut choisir en connaissance de cause.

5. Fixer ton TJM DevOps freelance en 2026

Les données 2026 donnent un marché actif, mais hétérogène. Free-Work indique un TJM moyen ingénieur DevOps cloud de 592 € en direct et 562 € via intermédiaire. La page missions DevOps cloud de Free-Work mentionne aussi un repère junior autour de 530 €.

Notre grille TJM développeur freelance 2026 positionne les profils DevOps/SRE entre 450 et 550 € pour un junior, 600 et 700 € pour un confirmé, puis 750 et 900 € pour un senior.

Fourchettes réalistes par profil

Profil DevOps freelance	Expérience	Missions typiques	TJM 2026 indicatif
Junior confirmé	2-3 ans tech, peu de freelance	CI/CD simple, Docker, scripts, support encadré	450-550 €/jour
Intermédiaire	3-5 ans production	Terraform, GitLab CI, cloud, observabilité	550-700 €/jour
Senior	5-8 ans production critique	Kubernetes, architecture, migration, SRE, incident	700-900 €/jour
Expert cloud critique	8 ans et plus	plateforme, multi-cloud, grands comptes, astreinte cadrée	900-1 100 €/jour

Ces fourchettes restent des repères HT. Ajuste selon :

• la région et le niveau de remote ;
• la durée de mission ;
• le passage en direct ou via ESN ;
• le niveau d’urgence ;
• l’accès production ;
• l’astreinte ;
• la criticité métier ;
• la rareté de la stack.

Une mission de 12 mois via ESN peut se signer à un TJM plus bas qu’une intervention courte et urgente sur une migration critique. Ce n’est pas incohérent. La durée réduit ton risque commercial, mais l’urgence et la responsabilité doivent se payer.

Calculer ton plancher avant de négocier

Ne pars jamais d’une grille seule. Calcule ton plancher avec tes charges, tes jours facturables et ton revenu cible.

Exemple simple :

• revenu net souhaité : 4 500 € par mois, soit 54 000 € par an ;
• cotisations micro-BNC 2026 : 25,6 % pour les professions libérales non réglementées relevant du régime général ;
• chiffre d’affaires nécessaire avant impôt : environ 72 600 € ;
• jours facturables réalistes : 145 jours ;
• TJM plancher : environ 500 €.

À 500 €, tu couvres ton objectif. Mais si le marché paie ton profil 650 €, ton prix final doit se rapprocher du marché. Ton plancher sert à ne pas perdre d’argent, pas à plafonner ta valeur.

Le guide comment fixer ses tarifs en freelance détaille cette méthode, et le simulateur de TJM permet de tester plusieurs scénarios.

Ton TJM DevOps doit intégrer la valeur technique, mais aussi l’exposition : production, horaires, responsabilité, documentation et disponibilité.

6. Construire un portfolio DevOps crédible

Le DevOps se vend mal avec une simple liste d’outils. Tout le monde peut écrire “Kubernetes, Terraform, AWS” sur un profil. Ce qui rassure, c’est la preuve.

Les preuves techniques à créer

Tu peux bâtir un portfolio sans exposer les données de tes anciens clients.

Crée deux ou trois preuves publiques :

• un lab cloud avec schéma d’architecture ;
• un pipeline GitLab CI ou GitHub Actions documenté ;
• un module Terraform réutilisable ;
• une application conteneurisée avec déploiement automatisé ;
• un dashboard Grafana avec données simulées ;
• un runbook de restauration ;
• un postmortem anonymisé ;
• une checklist de production readiness.

Chaque preuve doit répondre à trois questions :

1. Quel problème est traité ?
2. Quelle décision technique as-tu prise ?
3. Comment sait-on que c’est mieux après ?

Le cas client anonymisé

Un bon cas DevOps peut tenir en une page.

Structure simple :

Élément	Exemple
Contexte	équipe SaaS, déploiements manuels, incidents après release
Problème	rollback long, secrets dispersés, absence d’alertes utiles
Actions	pipeline GitLab, Terraform, séparation environnements, runbook
Résultat	déploiement plus prévisible, erreurs réduites, équipe autonome
Limites	chiffres anonymisés, contexte simplifié, périmètre non sensible

Tu n’as pas besoin de tout publier. Tu peux garder certains détails pour l’entretien, tant que ton profil montre une logique de résolution.

LinkedIn, Malt et dossier de compétences

Ton intitulé doit être spécifique.

Exemples :

• “DevOps freelance AWS, Terraform et GitLab CI pour équipes SaaS” ;
• “SRE freelance Kubernetes, observabilité et fiabilité production” ;
• “Platform Engineer freelance pour industrialiser CI/CD et infrastructure as code” ;
• “Cloud Ops freelance Azure, Terraform et MCO encadré”.

Sur Malt ou LinkedIn, évite la liste d’outils sans contexte. Relie chaque stack à un résultat : réduire les déploiements manuels, fiabiliser les rollbacks, améliorer les alertes, structurer les accès cloud.

Pour le format, tu peux reprendre les principes du CV freelance et dossier de compétences. Les ESN et grands comptes aiment les fiches lisibles, avec stack, contexte, rôle, livrables et disponibilité.

7. Choisir le bon statut quand ton TJM monte vite

Un DevOps freelance peut dépasser rapidement les plafonds de la micro-entreprise. À 600 €/jour, 140 jours facturés représentent 84 000 € de chiffre d’affaires. À 700 €/jour, 120 jours suffisent déjà à atteindre 84 000 €.

En 2026, le plafond micro pour les prestations de services et activités libérales est de 83 600 € de chiffre d’affaires HT, selon Service-Public et l’Urssaf. La franchise en base de TVA pour les prestations de services repose, elle, sur un seuil de base à 37 500 € et un seuil majoré à 41 250 €, comme le rappelle Service-Public.

Micro-entreprise pour tester

La micro-entreprise reste pratique pour démarrer :

• création simple ;
• charges calculées sur le chiffre d’affaires encaissé ;
• comptabilité légère ;
• bon format pour une première mission ou du side project.

Mais elle a des limites :

• pas de déduction réelle des frais cloud, matériel, formation, coworking ou expert-comptable ;
• plafond vite atteint ;
• TVA à gérer dès que la franchise est dépassée ;
• crédibilité parfois plus faible sur certains grands comptes ;
• protection sociale limitée.

Pour un DevOps qui démarre avec un TJM à 500 €, elle peut suffire quelques mois. Pour une mission longue à 650 ou 750 €, prépare la suite.

Si tu veux éviter de découvrir le dépassement trop tard, le simulateur de seuil TVA t’aide à projeter ton chiffre d’affaires avant de signer une mission longue.

EI au réel, EURL, SASU ou portage salarial

Statut	Quand l’envisager	Point de vigilance
EI au réel	tu veux rester indépendant sans société tout en déduisant tes frais	protection du patrimoine, comptabilité plus complète
EURL	tu veux une structure stable avec rémunération TNS	cotisations, dividendes, arbitrage avec expert-comptable
SASU	tu veux une protection sociale assimilée salarié et une image société	charges sur salaire plus élevées, coût administratif
Portage salarial	tu veux tester sans gérer société, surtout via grand compte	frais de portage, autonomie réelle, marge nette

Le bon choix dépend de ton chiffre d’affaires prévisible, de ton besoin de protection sociale, de ton niveau de frais, de ton rapport au risque et des exigences clients. Si tu hésites entre société et micro, commence par le guide micro-entreprise ou SASU puis compare avec EURL ou SASU pour freelance.

Une fois la décision prise, la création ne doit pas devenir un chantier. Legalstart monte l’EURL ou la SASU de bout en bout, jusqu’au Kbis, pendant que tu restes concentré sur ta mission en cours.

8. Cadrer le contrat avant de toucher à la production

La production n’est pas un terrain vague. Si tu as les droits pour casser, tu dois avoir le contrat de mission freelance pour te protéger.

Astreinte et horaires

L’astreinte salariée a un cadre légal spécifique, détaillé par Service-Public. En freelance, on ne transpose pas automatiquement ce cadre, mais le principe reste utile : une disponibilité hors horaires doit être prévue, organisée et compensée.

Dans ton contrat, précise :

• les plages horaires incluses dans le TJM ;
• les plages d’astreinte ;
• le délai de réponse attendu ;
• le délai d’intervention ;
• le tarif d’astreinte ;
• le tarif d’intervention hors plage ;
• les cas exclus ;
• la procédure de déclenchement.

Une astreinte non cadrée n’est pas un signe de confiance. C’est une dette contractuelle qui finit par tomber sur toi.

Tu peux facturer l’astreinte de plusieurs façons : forfait hebdomadaire de disponibilité, majoration des heures d’intervention, TJM majoré sur période sensible, ou retainer production avec périmètre strict.

SLA, responsabilité et obligation de moyens

Fais attention aux SLA que tu signes.

Un freelance DevOps peut s’engager à mettre en place des moyens, documenter, intervenir dans un délai prévu, appliquer une procédure, produire un plan d’amélioration. En revanche, garantir seul une disponibilité de 99,99 % sur un système que tu ne contrôles pas entièrement est dangereux.

À cadrer :

• responsabilité limitée au montant assuré ou à un plafond contractuel ;
• exclusions si le client modifie l’infrastructure sans validation ;
• validation écrite avant changement production ;
• rollback plan pour les interventions sensibles ;
• sauvegardes vérifiées avant migration ;
• accès minimum nécessaire ;
• journalisation des actions ;
• propriété des scripts et livrables.

Une RC Pro adaptée est fortement recommandée, et souvent exigée par les ESN ou grands comptes. Sur les missions critiques, vérifie que ton assureur couvre bien le conseil IT, l’infrastructure, la perte de données et les interruptions de service selon ton activité réelle.

Régie, forfait et recette des livrables

La plupart des missions DevOps longues se signent en régie : tu factures des jours, tu participes aux rituels, tu avances avec l’équipe et tu produis des livrables au fil de l’eau. C’est souvent le format le plus adapté quand le système est complexe ou mal documenté.

Le forfait peut fonctionner pour un audit, un lab, une migration limitée, un module Terraform ou un pipeline modèle. Mais évite le forfait sur une production inconnue avec dépendances multiples, dette historique et validation floue. Tu porterais un risque que tu ne maîtrises pas.

Pour chaque livrable, écris une définition de fini :

• dépôt ou module livré ;
• documentation associée ;
• tests ou démonstration attendus ;
• environnement concerné ;
• procédure de rollback ;
• critères de recette ;
• période de garantie ou de correction ;
• transfert de connaissance prévu.

Un livrable DevOps n’est pas seulement du code qui tourne. C’est un actif exploitable par l’équipe quand tu n’es plus là.

Cette précision protège les deux côtés. Le client sait ce qu’il reçoit. Toi, tu évites que “corriger deux ajustements” devienne trois semaines de support gratuit après la fin de la mission.

Accès production, sécurité et confidentialité

Demande un accès nominatif, jamais un compte partagé. Les droits doivent être proportionnés à la mission.

Bonnes pratiques contractuelles :

• MFA obligatoire ;
• gestionnaire de secrets validé ;
• pas de copie de données client hors environnement autorisé ;
• révocation des accès en fin de mission ;
• confidentialité renforcée sur architecture, incidents, coûts et vulnérabilités ;
• procédure d’urgence écrite ;
• transfert de connaissance prévu avant départ.

Si le client impose du présentiel pour accéder à certains environnements, vérifie que c’est cohérent avec le besoin. Le guide sur le présentiel obligatoire en freelance détaille les limites à poser.

Éviter la mission support sans fin

Le support est utile. Le support illimité détruit ton planning.

Définis :

• un volume de tickets inclus ;
• des catégories de demandes ;
• un niveau de priorité ;
• un temps réservé aux chantiers de fond ;
• un comité hebdomadaire de priorisation ;
• une règle de sortie pour les sujets hors périmètre.

Si un client représente 80 % de ton chiffre d’affaires pendant 12 mois, garde aussi un canal de prospection actif. Le guide sur la dépendance économique en freelance explique pourquoi ce sujet dépasse la simple trésorerie.

9. Trouver tes premières missions DevOps freelance

Le marché DevOps se joue beaucoup par signaux de confiance. Les clients te donnent parfois des accès critiques. Ils veulent savoir si tu es compétent, mais aussi fiable.

Plateformes IT et jobboards spécialisés

Commence par observer les missions avant de postuler.

Regarde :

• Free-Work ;
• Malt ;
• Freelance-Informatique ;
• LeHibou ;
• LinkedIn ;
• Crème de la Crème ;
• sites d’ESN spécialisées cloud ;
• cabinets de recrutement IT.

Analyse les annonces par stack, durée, remote, secteur, niveau de responsabilité et mots flous. “MCO”, “astreinte”, “production critique”, “run”, “support N3” et “incident” ne sont pas des problèmes en soi. Ce sont des signaux à clarifier.

ESN, cabinets cloud et intégrateurs

Les missions DevOps longues passent souvent par des ESN, surtout chez les grands comptes. Ce canal peut être efficace si tu comprends la marge, le référencement et les délais de paiement.

Le guide travailler avec une ESN en freelance détaille les clauses à surveiller : marge, préavis, non-sollicitation, CRA, paiement, client final et renouvellement.

Quand tu échanges avec une ESN, pose des questions précises :

• qui est le client final ;
• quelle stack est réellement en place ;
• qui porte l’astreinte ;
• combien de jours de remote sont acceptés ;
• quel est le budget TJM validé ;
• quelle durée est financée ;
• pourquoi le besoin est ouvert maintenant ;
• qui valide ton profil techniquement.

Une ESN sérieuse sait répondre à la plupart de ces points. Si tout est vague, protège ton temps.

Réseau, anciens collègues et éditeurs

Le meilleur canal reste souvent ton réseau technique.

Contacte :

• anciens CTO ;
• lead developers ;
• administrateurs système ;
• cloud architects ;
• responsables produit ;
• commerciaux ESN sérieux ;
• consultants cyber ou FinOps ;
• éditeurs SaaS que tu connais ;
• partenaires AWS, Azure ou GCP locaux.

Message simple :

“Je me positionne en DevOps freelance sur AWS, Terraform et GitLab CI, avec un angle fiabilisation des déploiements. Si tu vois passer une équipe qui a des releases fragiles ou une infrastructure Terraform à remettre au propre, je peux faire un audit court ou une mission d’industrialisation.”

Ce message est plus fort qu’un “je suis disponible pour missions DevOps”. Il nomme un problème.

10. Te positionner en 90 jours

Tu peux poser les bases d’une offre DevOps freelance en trois mois. L’objectif n’est pas de devenir expert absolu. L’objectif est d’avoir une stack claire, deux preuves techniques, un profil lisible et des conversations commerciales.

Jours 1-30 : choisir une stack et cadrer ton offre

• Choisis un positionnement principal : AWS Terraform, Azure DevOps, Kubernetes SRE, GitLab CI, Cloud Ops MCO.
• Liste tes expériences production, même salariées.
• Sélectionne 3 problèmes que tu sais résoudre : pipeline lent, infra non documentée, alertes bruyantes, accès cloud, rollback absent.
• Écris une phrase d’offre.
• Fixe ton TJM cible et ton TJM plancher.
• Mets à jour ton CV freelance.

Phrase d’offre possible :

“J’aide les équipes SaaS à fiabiliser leurs déploiements AWS avec Terraform, GitLab CI et une observabilité exploitable.”

Jours 31-60 : créer deux preuves techniques

Crée deux livrables visibles.

Preuve 1 : un lab cloud documenté.

• architecture simple ;
• Terraform ;
• pipeline ;
• monitoring ;
• README clair ;
• coûts estimés ;
• limites assumées.

Preuve 2 : un runbook ou postmortem anonymisé.

• incident simulé ;
• symptômes ;
• diagnostic ;
• actions ;
• rollback ;
• prévention ;
• checklist.

Ces preuves montrent ton raisonnement. C’est ce qu’un client achète en réalité.

Jours 61-90 : prospecter sans attendre d’être parfait

• Refaire LinkedIn avec ton angle DevOps précis.
• Refaire Malt avec 3 cas d’usage et une fourchette TJM.
• Contacter 20 personnes ciblées.
• Écrire à 5 ESN ou cabinets cloud.
• Répondre à 5 missions pertinentes.
• Publier 2 posts techniques courts.
• Proposer 3 audits exploratoires payants ou cadrés gratuitement sur 30 minutes.

Ton objectif à 90 jours : obtenir des retours de marché. Si tout le monde te parle de Kubernetes mais que ton portfolio ne le montre pas, tu sais quoi renforcer. Si les clients veulent surtout du support production, tu peux décider de l’accepter avec astreinte payée ou de déplacer ton positionnement vers CI/CD et IaC.

Ton plan d’action pour devenir DevOps freelance

Devenir DevOps freelance en 2026, ce n’est pas empiler des logos d’outils sur un profil. C’est choisir le type de problème production que tu veux résoudre, montrer que tu sais le traiter et refuser les périmètres qui transforment ton expertise en disponibilité permanente.

Ton plan immédiat :

1. Choisis ton angle : DevOps CI/CD, SRE, Cloud Ops, Platform Engineering ou DevSecOps.
2. Sélectionne une stack défendable en entretien.
3. Crée deux preuves techniques publiques ou anonymisées.
4. Calcule ton TJM plancher puis compare-le au marché.
5. Cadre l’astreinte, les SLA, la responsabilité et les accès avant de signer.
6. Active 20 contacts ciblés avec une phrase d’offre claire.

Le marché DevOps freelance est porteur, mais il récompense les profils qui savent poser un cadre. Tu peux être utile sans devenir indispensable au mauvais sens du terme.

FAQ

Questions fréquentes

Faut-il être développeur pour devenir DevOps freelance ? +

Non, mais il faut comprendre le cycle de livraison logiciel. Un ancien administrateur système, cloud engineer, ingénieur production ou support N3 peut devenir DevOps freelance s'il maîtrise Git, CI/CD, scripting, cloud et collaboration avec les équipes produit. Une expérience de développement aide beaucoup pour comprendre les contraintes des développeurs, mais elle n'est pas le seul chemin.

Quel TJM demander comme DevOps freelance en 2026 ? +

En 2026, un DevOps freelance junior confirmé peut viser 450 à 550 € HT par jour, un profil intermédiaire 550 à 700 €, un senior 700 à 900 €, et un expert cloud ou SRE critique 900 à 1 100 €. Le tarif dépend de la stack, de la région, du remote, de l'ESN éventuelle, de l'astreinte, de la durée et de l'accès production.

Peut-on commencer DevOps freelance en micro-entreprise ? +

Oui, la micro-entreprise peut servir à tester l'activité. Mais le plafond 2026 des prestations de services et activités libérales est de 83 600 € de chiffre d'affaires HT. Avec un TJM DevOps de 600 à 700 €, ce plafond arrive vite. Il faut donc anticiper l'EI au réel, l'EURL, la SASU ou le portage salarial selon ton niveau de risque, tes frais et les exigences clients.

Faut-il accepter l'astreinte en mission DevOps ? +

Tu peux accepter l'astreinte si elle est écrite, limitée, rémunérée et associée à une procédure claire. Refuse les formulations vagues du type disponibilité ponctuelle ou support si besoin. Il faut préciser les horaires, le délai de réponse, le tarif, les priorités, les cas exclus et la personne qui décide en incident.

Quelles certifications DevOps valent le coup ? +

Les certifications les plus utiles dépendent de ta stack : AWS Solutions Architect ou SysOps, Azure Administrator ou Solutions Architect, Google Professional Cloud DevOps Engineer, Certified Kubernetes Administrator, Terraform Associate et GitLab CI/CD Specialist. Elles aident à passer les filtres, surtout via ESN, mais elles doivent être complétées par des preuves techniques.

Kubernetes est-il obligatoire pour devenir DevOps freelance ? +

Non. Kubernetes est très demandé, mais beaucoup de missions DevOps portent sur CI/CD, Terraform, cloud managé, Docker, observabilité, Ansible ou MCO. En revanche, si tu affiches Kubernetes sur ton profil, tu dois savoir diagnostiquer un cluster réel : RBAC, ingress, logs, ressources, Helm, montée de version et incidents.

Comment éviter les missions support production sans fin ? +

Cherche le livrable avant de signer. Le contrat doit distinguer support, astreinte, amélioration continue, incidents, projets et transfert de connaissance. Prévois un volume de tickets, des priorités, des horaires, un comité de tri et une règle de sortie pour les demandes hors périmètre.

Quelle différence entre DevOps et SRE ? +

Le DevOps se concentre surtout sur l'automatisation de la livraison, l'infrastructure et la collaboration entre développement et opérations. Le SRE met la fiabilité au centre : SLO, disponibilité, incidents, observabilité, postmortems et réduction du risque opérationnel. Les deux rôles se croisent, mais ils ne vendent pas exactement la même valeur.