Aller au contenu
agencedevops.fr

Cahier des charges DevOps : le modèle à remplir et les clauses à ne pas oublier

Un bon cahier des charges DevOps tient en une quinzaine de pages : un inventaire chiffré de l’existant, des objectifs mesurables, des niveaux de service, une clause de réversibilité et un format de prix imposé. Sans ces cinq éléments, les offres reçues ne sont pas comparables.

Par la rédaction d’agencedevops.fr · données vérifiées le · méthode

Le plan type en neuf sections

  1. Contexte : activité, utilisateurs, enjeux du projet, calendrier imposé (fin de contrat d’hébergement, levée de fonds, audit à venir).
  2. Existant technique : inventaire chiffré, voir la section suivante.
  3. Périmètre de la prestation : ce qui est confié et ce qui reste chez vous, écrit sous forme de tableau de responsabilités.
  4. Objectifs mesurables : fréquence de mise en production visée, délai de déploiement, taux de disponibilité, budget cloud mensuel cible.
  5. Exigences de service : plages de service, astreinte, délais de prise en charge et de rétablissement, sauvegardes, objectifs de reprise.
  6. Exigences de sécurité et de conformité : données traitées, localisation, certifications attendues, contraintes sectorielles.
  7. Gouvernance : interlocuteurs, comités, indicateurs, rapports mensuels.
  8. Réversibilité : livrables de sortie, durée et prix de l’accompagnement.
  9. Modalités de réponse : bordereau de prix imposé, calendrier, critères et pondération.

L’inventaire de l’existant : la partie qui fait les bons prix

Un prestataire qui ne connaît pas votre environnement chiffre le risque, pas le travail. Fournissez au minimum, dans une annexe tableur :

  • la liste des serveurs ou machines virtuelles, avec système d’exploitation, version, rôle, environnement et hébergeur ;
  • les bases de données, leur moteur, leur version et leur volume ;
  • les applications et leurs langages, la façon dont elles sont déployées aujourd’hui, à la main, par script ou par une chaîne d’intégration continue ;
  • la facture cloud ou d’hébergement des trois derniers mois, poste par poste ;
  • les incidents des douze derniers mois et leur durée ;
  • la documentation existante et son état réel.

Si cet inventaire n’existe pas, faites-le réaliser d’abord. Un diagnostic de deux à cinq jours, facturé à part, coûte moins cher qu’une consultation dont toutes les offres sont assorties de réserves.

Le tableau des responsabilités

Le désaccord le plus fréquent en cours de contrat porte sur « qui fait quoi ». Écrivez-le activité par activité : mises à jour de sécurité du système, mises à jour des applications, gestion des comptes, sauvegardes, restauration testée, supervision, réponse aux alertes la nuit, gestion de la facture cloud. Pour chaque ligne, une seule entreprise est responsable, les autres sont consultées ou informées.

Les niveaux de service à chiffrer

Exemple de grille à adapter, pas une norme
Indicateur Exemple d’exigence Comment la mesurer
Prise en charge d’un incident bloquant 30 minutes, 24 h sur 24 horodatage du ticket et de la première action
Rétablissement d’un incident bloquant 4 heures du signalement au retour du service
Disponibilité de la production 99,9 % par mois sonde externe, rapport mensuel
Sauvegardes quotidiennes, conservées 30 jours, une copie hors site rapport de sauvegarde, test de restauration trimestriel
Objectif de reprise (RTO) et perte maximale de données (RPO) RTO 8 heures, RPO 24 heures exercice de reprise annuel documenté
Correctifs de sécurité critiques appliqués sous 7 jours rapport de conformité des systèmes

Chaque engagement doit dire comment il est mesuré et qui fournit la mesure. Un 99,9 % sans sonde externe ni rapport ne se vérifie pas. Gardez aussi en tête que 99,9 % par mois autorise environ 43 minutes d’indisponibilité : si votre activité ne le supporte pas, il faut une architecture redondante, et le prix change.

Sécurité et conformité

Précisez la nature des données : données personnelles, données de santé, données financières, données sensibles pour un acheteur public. Elles déterminent les exigences de localisation et de certification. L’hébergement de données de santé suppose un prestataire certifié HDS ; certaines données publiques sensibles, une offre qualifiée SecNumCloud ; une entité financière soumise à DORA doit faire figurer dans le contrat les clauses prévues par l’article 30 du règlement, dont les droits d’audit et les stratégies de sortie. Le guide de l’ANSSI sur l’infogérance détaille les clauses de sécurité à intégrer : il reste la meilleure base de départ pour un acheteur qui n’a pas de juriste spécialisé.

La réversibilité, écrite dès le départ

  • Le code d’infrastructure (Terraform, Ansible, manifestes Kubernetes) est versionné dans un dépôt qui vous appartient.
  • Les comptes cloud sont ouverts à votre nom et facturés à votre entreprise ; le prestataire y accède par des rôles nominatifs.
  • La documentation d’exploitation est tenue à jour et remise à chaque comité trimestriel.
  • La phase de sortie a une durée et un prix fixés dans l’offre, avec un transfert de connaissances au repreneur.

Imposer le format de prix

Pour comparer, exigez le même bordereau de tous les candidats : forfait de mise en place, forfait mensuel d’exploitation par environnement ou par serveur, prix unitaires des profils pour les évolutions, coût de l’astreinte, prix de la réversibilité. Demandez séparément les coûts d’hébergement ou de cloud refacturés, sans marge cachée. Les repères de prix des prestations DevOps et les données des marchés publics aident à repérer une offre anormalement basse.

Avant d’envoyer : la liste de contrôle

  • L’inventaire est chiffré et joint en annexe.
  • Chaque niveau de service a une méthode de mesure.
  • Le tableau des responsabilités ne laisse aucune activité sans responsable.
  • La réversibilité a un prix et une durée.
  • Les critères de choix et leur pondération sont écrits.
  • Une séance de questions est prévue, avec réponses partagées à tous les candidats.

Vous pouvez aussi faire relire votre projet de cahier des charges : décrivez votre besoin ci-dessous.

Questions fréquentes

Quelle différence entre cahier des charges fonctionnel et technique ?

Le cahier des charges fonctionnel décrit le résultat attendu, par exemple « déployer une nouvelle version en production sans interruption de service ». Le technique impose des moyens, par exemple « Kubernetes sur OVHcloud, déploiements par GitLab CI ». Pour une prestation DevOps, partez du fonctionnel et n’imposez que les contraintes réelles : outils déjà payés, hébergeur imposé, exigences de sécurité.

Quelles sont les quatre parties indispensables ?

Le contexte et l’existant, le besoin et les objectifs mesurables, les exigences (niveaux de service, sécurité, réversibilité), et les modalités de réponse : format de prix, calendrier, critères de choix.

Faut-il donner le budget dans le cahier des charges ?

Une fourchette aide les candidats à proposer une solution au bon niveau et évite des écarts de un à cinq entre les offres. Si vous ne voulez pas l’écrire, indiquez au moins l’ordre de grandeur de votre facture cloud et la taille de l’équipe interne.

Combien de temps laisser aux candidats pour répondre ?

Trois à quatre semaines pour une consultation d’exploitation ou de migration, avec une séance de questions à mi-parcours. Moins de deux semaines écarte les entreprises qui chiffrent sérieusement.

Sources