Une mise en production prend presque tout le vendredi après-midi. Un seul développeur connaît la procédure, et personne ne veut s'en charger pendant ses vacances. On pourrait automatiser le déploiement, mais il faut d'abord comprendre quelles étapes sont nécessaires et pourquoi la dernière tentative a échoué. Voilà une mission pour laquelle un consultant DevOps peut être utile.
Le conseil DevOps porte sur la façon de développer, de déployer et d'exploiter des logiciels. Selon l'entreprise, il peut s'agir de réparer une chaîne de déploiement ou de prendre en charge toute une plateforme cloud. Des prestations très différentes sont ainsi proposées sous le même intitulé.
Reprenez le déroulement d'une mise en production
Avant de demander des offres, discutez avec les personnes qui ont effectué le dernier déploiement. À quels moments ont-elles attendu ? Quelles étapes nécessitaient un accès particulier ? En cas d'échec, comment auraient-elles rétabli la version précédente ?
La chaîne s'exécute peut-être en dix minutes, alors que la validation prend trois jours. Ou tous les tests passent, mais l'environnement de test diffère tellement de la production que personne ne se fie au résultat. Ces situations appellent des interventions différentes. Décrivez au prestataire les étapes manuelles, même les plus fastidieuses : elles peuvent expliquer une bonne partie du problème.
Les indicateurs DORA donnent un point de départ pour les mesures. Ils couvrent le délai de mise en production des changements, la fréquence des déploiements, le rétablissement après un déploiement échoué, les échecs et les reprises. Appliquez-les à une application à la fois. Une livraison hebdomadaire peut suffire pour un système et retarder inutilement le travail sur un autre.
Définissez ce qui aiderait concrètement votre équipe. Pour le déploiement du vendredi, vous pourriez demander qu'un second développeur sache l'effectuer pendant les heures de travail et démontrer un retour à la version précédente. C'est un résultat que vous pourrez vérifier à la réception.
Que faut-il inclure dans la mission ?
Demandez au prestataire de préciser ce qu'il livrera et les tâches qui resteront à votre équipe. Des formulations comme « mettre en place l'observabilité » ou « adopter l'infrastructure as code » laissent beaucoup de place à l'interprétation.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| Travail | À préciser dans l'offre | Exemple de vérification à la réception |
|---|---|---|
| CI/CD | Compilation, tests, droits de déploiement, secrets, validations et retour arrière | Un membre de votre équipe sait déployer et revenir en arrière après un échec |
| Infrastructure as code | Configuration versionnée, modules réutilisables, stockage de l'état et procédure de mise à jour | Votre équipe peut recréer un environnement et examiner une modification avant de l'appliquer |
| Mise en place ou migration cloud | Comptes, réseau, accès, ordre des migrations et arrêt de l'ancienne installation | L'application fonctionne après la bascule et les anciennes ressources ne sont plus facturées |
| Supervision | Métriques, journaux, traces, alertes et durées de conservation | Un ingénieur peut rechercher la cause d'une requête échouée avec les données recueillies |
| Fiabilité | Disponibilité attendue, sauvegardes, restauration et responsabilités en cas d'incident | Une restauration a été testée et une personne est chargée de répondre aux alertes |
| Sécurité | Accès à la chaîne, contrôle des dépendances, gestion des secrets et correction des vulnérabilités | L'équipe sait qui peut publier du code et qui traite un contrôle de sécurité échoué |
| Coûts cloud | Attribution des dépenses, ressources inutilisées, capacité et alertes budgétaires | Vous pouvez expliquer la facture par application ou par équipe et repérer une hausse inattendue |
OpenTelemetry permet de collecter les données de fonctionnement et de les transmettre à différents outils. Il reste à décider quels événements conserver, pendant combien de temps et quelles pannes justifient de réveiller quelqu'un. Ce travail doit aussi figurer dans la mission de supervision.
Pour préparer les exigences de sécurité, le Secure Software Development Framework du NIST fournit une base utile. Demandez au prestataire comment il traite une dépendance vulnérable ou un identifiant divulgué. La présence d'un outil d'analyse dans la chaîne ne dit pas qui s'occupera de ses résultats.
Si l'offre prévoit Kubernetes
Faites préciser le besoin de vos applications auquel Kubernetes répond. Il peut être utile pour répartir et gérer de nombreuses applications conteneurisées. Le cluster demande toutefois un entretien : droits d'accès, réseau, mises à jour et procédures de reprise.
L'étude de cas adidas publiée par la CNCF donne un exemple concret. adidas a fait appel à Giant Swarm pour installer et exploiter Kubernetes, tandis que ses développeurs se concentraient sur le commerce en ligne. L'étude, publiée en 2019, rapporte un passage d'une mise en production toutes les quatre à six semaines à trois ou quatre par jour. Elle décrit aussi une équipe plateforme de 35 personnes pour environ 300 ingénieurs.
Cet effectif compte dans la comparaison. Pour quelques applications gérées par une petite équipe, demandez également un chiffrage avec un service de conteneurs managé ou une plateforme en tant que service. Le calcul doit inclure l'exploitation, notamment les mises à jour et le support en dehors des heures de bureau.
La question se pose aussi pour une plateforme interne de développement. Elle peut permettre aux équipes de créer leurs environnements et de déployer elles-mêmes. Les modèles de configuration doivent néanmoins être entretenus, et les développeurs accompagnés. DORA recommande de commencer avec une plateforme minimale. Choisissez une tâche qui pose régulièrement problème, simplifiez-la et vérifiez que les équipes utilisent la solution avant de l'étendre.
Convenez des tâches confiées au prestataire et de celles qui restent à votre équipe.
Quel budget prévoir ?
Chez Alpine Edge, le tarif d'ingénierie DevOps est de CHF 100 par heure.
Pour estimer le travail, il faut connaître les applications et environnements concernés, l'existant et les personnes qui fourniront les accès. Demandez une estimation des heures par tâche et convenez d'un plafond de dépenses avant la réalisation. Prévoyez aussi les revues, la documentation et le transfert à votre équipe.
En comparant les offres, vérifiez qui fera le travail. La personne qui conçoit l'architecture participera-t-elle à sa réalisation ? Combien de temps vos propres ingénieurs devront-ils y consacrer ?
Aux honoraires s'ajoutent les frais récurrents : serveurs de compilation, bases de données managées ou stockage des journaux, par exemple. Pendant une migration, les anciennes et les nouvelles installations peuvent être facturées en parallèle. L'astreinte peut faire l'objet d'un contrat séparé. Demandez une estimation mensuelle d'exploitation en plus du prix de réalisation, avec les hypothèses de calcul.
Un forfait suppose un périmètre défini : applications et environnements concernés, interfaces, déroulement de la migration et tests de réception. Si ces éléments restent flous, une courte évaluation peut permettre de chiffrer la suite. Pour une mission facturée au temps passé, convenez de la manière de suivre les dépenses et le travail restant.
Quelle collaboration votre équipe peut-elle gérer ?
Une migration ponctuelle peut se traiter comme un projet avec une fin précise. Si votre équipe maîtrise déjà l'architecture mais manque d'expérience sur un élément, un spécialiste travaillant à ses côtés peut convenir. L'exploitation continue demande un autre type d'accord.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| Forme de collaboration | Quand elle est utile | À régler avant de signer |
|---|---|---|
| Évaluation | Vous devez comprendre le problème avant de lancer la réalisation | Quels systèmes seront examinés, et les conclusions comprendront-elles un plan de travail applicable ? |
| Projet délimité | Le résultat et sa réception peuvent être décrits | Que se passe-t-il si une dépendance ou une hypothèse de migration se révèle incorrecte ? |
| Spécialiste dans votre équipe | Il vous manque une compétence ou une capacité temporaire | Qui dirige le travail, et comment les collègues apprendront-ils à maintenir la solution ? |
| Exploitation par le prestataire | Vous souhaitez lui confier la plateforme dans la durée | Qui répond aux incidents, que couvre le contrat hors horaires de bureau et comment peut-on en sortir ? |
Même si l'exploitation est confiée à un prestataire, désignez un responsable interne de la relation. Il doit suffisamment comprendre le système pour évaluer les changements, approuver les coûts et expliquer le travail effectué.
Si votre équipe doit reprendre la main, préparez le transfert pendant le projet. Donnez aux collaborateurs accès aux dépôts et aux comptes cloud. Faites-les participer aux revues et réaliser les modifications courantes tant que le consultant est disponible. Découvrir à la fin que lui seul sait déployer complique beaucoup la reprise.
Comment vérifier que le travail est terminé ?
Le planning doit laisser du temps aux imprévus. Une migration peut révéler une dépendance à une base de données non documentée. Un test de restauration peut échouer parce qu'il manque une clé. Demandez comment ces investigations sont prises en compte et qui autorise un éventuel supplément.
Essayez la solution sur une application réelle avant de migrer les suivantes. Convenez des vérifications à l'avance. Selon la mission, elles peuvent inclure un déploiement, un retour arrière, une restauration de données et un contrôle des droits d'accès. Les résultats permettent de décider si la migration peut se poursuivre.
Lors du transfert, demandez à un membre de votre équipe de suivre les instructions d'exploitation : trouver le bon journal, modifier un réglage et expliquer la procédure de reprise. Le consultant pourra encore corriger les lacunes. C'est à l'usage que l'on voit si une documentation est compréhensible.
Une intervention plus limitée peut suffire
Le passage au cloud peut être nécessaire parce qu'un centre de données ferme ou qu'un contrat matériel arrive à son terme. Précisez ce motif. Si vous attendez aussi des livraisons plus rapides ou moins d'administration, la mission doit prévoir les changements correspondants. Reproduire les serveurs existants sous forme de machines virtuelles cloud peut laisser les mêmes procédures manuelles en place. Les travaux DORA sur l'infrastructure flexible abordent ces migrations sans évolution du fonctionnement des équipes.
Pour les coûts, commencez par vérifier si vous pouvez expliquer la facture. À qui appartient chaque ressource ? Quels environnements de test tournent tout le week-end ? Quelles règles de conservation des journaux ont été configurées une fois, puis oubliées ? Ces questions peuvent déjà définir une première intervention raisonnable.
Vous pouvez également arrêter le chantier lorsque les déploiements sont reproductibles et la restauration fiable. Une petite équipe n'a pas forcément besoin d'un catalogue de services ou d'un portail de développement sur mesure. Demandez qui le maintiendrait et combien de temps il ferait gagner aux utilisateurs.
Vérifiez les accès accordés au prestataire
Un prestataire DevOps peut avoir besoin d'accéder au code source, aux journaux de production, aux bases de données et aux sauvegardes. Identifiez les personnes concernées, leur lieu de travail et les éventuels sous-traitants. Précisez comment les accès sont accordés puis retirés quand quelqu'un quitte le projet.
Pour une entreprise suisse, le lieu d'hébergement n'est qu'une partie de l'examen des traitements de données. Le PFPDT explique les conditions de communication à l'étranger. Vérifiez où vont les journaux, les sauvegardes et les accès du support, en plus du lieu où tourne l'application. Votre secteur ou vos contrats clients peuvent aussi imposer des conditions.
Lorsque le RGPD s'applique, les articles 28 et 32 encadrent la sous-traitance et les mesures de sécurité ; le chapitre V concerne les transferts internationaux. Faites examiner les dispositions contractuelles pour votre situation. Les organismes financiers concernés dans l'UE peuvent aussi avoir des obligations au titre du règlement sur la résilience opérationnelle numérique, notamment pour la surveillance des prestataires informatiques. Ce règlement est lui aussi abrégé DORA, sans rapport avec le programme de recherche cité plus haut.
Si la plateforme doit exploiter des systèmes d'IA, incluez-les dans cet examen. L'accès aux modèles, les requêtes conservées et les historiques de déploiement peuvent ajouter des responsabilités. Notre guide de l'IA auto-hébergée détaille les choix d'hébergement et d'exploitation.
Que doit laisser une évaluation technique ?
Une évaluation doit vous permettre de choisir les travaux à engager. Demandez un schéma simple de l'application, de ses dépendances et du parcours d'un changement jusqu'à la production. Les personnes en font aussi partie : une mise en production qui attend toujours la validation du même collègue dépend de sa disponibilité.
Le compte rendu doit distinguer les vérifications effectuées des points restés ouverts. « Les sauvegardes sont configurées » ne signifie pas « Nous avons restauré une sauvegarde avec succès ». Notez les accès manquants et les environnements de test indisponibles pour en tenir compte dans l'estimation.
Un plan de travail utile précise le premier changement, sa raison, l'effort prévu et la personne qui le validera. Il indique aussi ce qui peut attendre. Si tout paraît urgent, demandez quel problème mériterait d'être résolu si le budget ne permettait qu'une seule intervention.
Comparer les prestataires sur le même exemple
Présentez la même mise en production ou le même incident à chaque candidat. Comment chercherait-il la cause ? De quels accès aurait-il besoin ? Que pourrait essayer votre équipe à la fin ? Ses questions vous en apprendront souvent plus qu'une présentation remplie de noms d'outils.
- Rencontrez l'ingénieur qui travaillerait avec vous, pas seulement la personne qui présente l'offre.
- Demandez un exemple de document de transfert, sans données confidentielles d'un client.
- Faites expliquer une option moins chère ou plus simple, et les raisons de la retenir ou de l'écarter.
- Précisez ce qui se passe lorsqu'une dépendance modifie l'estimation ou que vous arrêtez après le pilote.
Avant de comparer les montants, relevez les hypothèses de chaque offre. L'une peut inclure une répétition de migration et une formation, tandis qu'une autre laisse ces tâches à votre équipe. Un bref descriptif commun permet de repérer ces écarts.
Continuer les vérifications après la migration
Une fois l'application en service, désignez quelqu'un pour suivre la facture, les alertes et la maintenance à venir. Une alerte de dépenses doit arriver à une personne capable d'expliquer la hausse et de décider de la suite. Une étiquette de ressource aide à attribuer un coût ; elle n'arrête pas un environnement de test oublié.
Reprenez l'exemple de mise en production après quelques changements ordinaires. Un collègue peut-il déployer sans appeler le consultant ? La restauration a-t-elle fonctionné au test ? Quelqu'un copie-t-il encore des secrets ou modifie-t-il la production à la main ? Examinez ces observations avec les indicateurs de livraison. Si le nouveau fonctionnement est contourné, cherchez d'abord pourquoi avant d'ajouter de l'automatisation.
Que préparer pour le premier échange ?
Vous n'avez pas besoin d'un cahier des charges complet. Décrivez la dernière mise en production difficile, un incident récurrent ou une facture cloud que vous n'arrivez pas à expliquer. Indiquez aussi ce que votre équipe a déjà essayé et qui travaillerait avec le prestataire.
Chez Alpine Edge, une évaluation technique sert à examiner ce problème et à convenir du travail avant la réalisation. Nos prestations cloud et DevOps couvrent la mise en place et l'exploitation. Pour les équipes qui déploient des modèles, nous intervenons aussi sur l'intégration de l'IA et l'IA privée. Le premier échange doit permettre de préciser ce qui mérite d'être changé, ce que votre équipe peut prendre en charge et où une aide extérieure serait utile.