Le service attendu oriente la responsabilité à renforcer
Supposons que vos équipes demandent une mise en production plus simple. Si elles attendent une intervention sur un déploiement ou sur la supervision, vous pouvez cadrer un renfort DevOps autour de ce travail. Si elles attendent un service commun, maintenu et amélioré selon leurs besoins, il faut aussi attribuer une responsabilité de plateforme interne. Ces besoins peuvent coexister : leur distinction ne suffit à justifier ni un recrutement ni la création de deux équipes.
Le résultat à obtenir permet de préciser le choix. Un déploiement automatisé permet d’accomplir un travail opérationnel identifié. Pour un parcours commun vers la production, il faut également prévoir comment plusieurs équipes pourront l’utiliser et demander son évolution. Microsoft Learn décrit ainsi des parcours de développement vers la production recommandés et pris en charge par la plateforme. Nous vous proposons de partir de cette différence entre les résultats attendus, puis de vérifier qui peut les assurer.
Les demandes des équipes précisent le travail attendu
Demandez aux équipes de décrire une difficulté rencontrée, la réponse déjà apportée et ce qu’elles voudraient pouvoir faire ensuite. Faites préciser qui utilise le service concerné et qui intervient aujourd’hui lorsqu’il ne fonctionne pas. Vous cherchez à comprendre si la demande appelle une correction locale, une amélioration de l’exploitation ou une capacité réutilisable.
Dans une situation hypothétique, une équipe pourrait attendre l’automatisation d’une procédure manuelle, tandis que d’autres souhaiteraient réutiliser cette procédure sans solliciter son auteur à chaque déploiement. Dans le premier cas, examinez le temps consacré aux manipulations et à leurs reprises. Dans le second, prenez également en compte l’attente des utilisateurs et les interruptions de la personne sollicitée. Demandez aux équipes de documenter ces conséquences avant de retenir une réponse commune.
La CNCF, Cloud Native Computing Foundation, recommande de privilégier les usages communs à plusieurs équipes produit. Cela vous donne un critère de priorité, pas un seuil d’organisation. Une demande répétée mérite un examen, mais vous devez encore établir que les attentes des équipes sont suffisamment proches pour qu’un même service puisse y répondre. Le recours au même outil ne répond pas à cette question.
Pour interpréter les demandes recueillies, faites décrire le résultat attendu sans nommer de poste : une application dont la mise en production est automatisée, par exemple, ou un parcours que plusieurs équipes peuvent utiliser et dont quelqu’un organise l’évolution. Cette formulation permet de discuter du travail attendu avant que le choix d’un intitulé ne le fige.
Le renfort DevOps exige un mandat opérationnel explicite
Si le besoin porte sur la livraison et l’exploitation, décrivez les interventions attendues et la manière de constater leur réalisation. France compétences indique que le titre professionnel Administrateur système DevOps couvre la mise en production automatisée d’une application et la supervision des services déployés. Ce référentiel français décrit ces activités précises, sans décrire tous les postes DevOps ni garantir les compétences d’une personne.
Vous pouvez, par exemple, proposer un mandat d’automatisation de la mise en production d’une application. Faites préciser les étapes concernées, les personnes qui valident les changements et celles qui prendront ensuite en charge les alertes. Le livrable doit pouvoir être examiné : demandez une démonstration du déploiement et une explication des interventions qui restent nécessaires. La démonstration montre le fonctionnement observé, tandis que l’explication permet d’examiner les conditions d’exploitation.
Vérifiez ensuite les compétences, les accès aux environnements et le temps accordé aux personnes concernées. Un mandat qui décrit correctement le résultat mais laisse ces moyens indéterminés reste incomplet. Sa limite apparaît aussi si personne ne doit recueillir les demandes des utilisateurs d’un service commun ni arbitrer ses évolutions. Vous avez alors une responsabilité supplémentaire à attribuer, sans présumer qu’une personne portant un intitulé DevOps ne pourrait pas l’assumer.
La plateforme demande un pilotage de produit interne
Lorsque plusieurs équipes attendent des services communs, il faut décider lesquels construire, pour quels usages et dans quel ordre. La CNCF associe explicitement les responsabilités de plateforme à l’étude des besoins des utilisateurs et à la planification d’une feuille de route. Le travail ne s’arrête donc pas à la mise à disposition d’outils.
Pour un parcours commun de mise en production, nous proposons de demander aux personnes qui pourraient en être responsables une première description des utilisateurs, des difficultés à résoudre et des évolutions envisagées. Examinez comment elles distinguent une demande propre à une équipe d’un besoin partagé. Faites expliquer pourquoi une évolution serait prioritaire et quelle demande serait différée : vous pourrez ainsi discuter les arbitrages plutôt que valider une simple liste de fonctionnalités.
Attribuez ensuite la responsabilité de ces choix et vérifiez les moyens de l’exercer. La personne ou les personnes concernées doivent pouvoir échanger avec les utilisateurs, consacrer du temps à cette recherche et obtenir un arbitrage lorsque les demandes divergent. Si les besoins ou ces moyens restent flous, clarifiez-les avant de décider de créer une équipe plateforme. L’intitulé Platform Engineer ne suffit pas à établir que toutes ces responsabilités seront exercées.
La coexistence des besoins demande des arbitrages explicites
Un service commun peut nécessiter à la fois des travaux de déploiement et de supervision, une étude des besoins des utilisateurs et des choix d’évolution. Le questionnaire de recherche de DevOps Research and Assessment (DORA) précise qu’une équipe plateforme distincte n’est pas requise. Cette possibilité ne prouve toutefois pas que vos équipes disposent déjà des moyens de cumuler ces responsabilités.
Pour examiner ce cumul, demandez qui prend en charge la livraison et l’exploitation, qui échange avec les utilisateurs et qui décide de la feuille de route. Mettez cette répartition à l’épreuve d’une situation hypothétique : un incident mobilise la personne qui devait préparer une évolution attendue. Qui décide du report et informe les équipes utilisatrices ? La réponse permet de vérifier si l’arbitrage est attribué ou simplement laissé à la personne disponible.
Des responsabilités réunies peuvent rester explicites. À l’inverse, deux équipes ne règlent pas à elles seules les conflits de priorité. Examinez le temps disponible, les compétences et les décisions que chaque personne est autorisée à prendre avant de retenir une répartition.
La prochaine décision porte sur un mandat et ses moyens
Si le travail opérationnel est établi, formalisez le mandat du renfort DevOps et les conditions de son intervention. Si les services communs et leur pilotage sont documentés, attribuez la responsabilité de plateforme. Lorsque les deux besoins coexistent, faites valider la répartition des responsabilités correspondantes et la manière d’arbitrer les priorités avant d’engager un recrutement.
Si vous ne pouvez pas encore décrire le résultat attendu ou nommer les personnes capables de l’obtenir, la prochaine action consiste à compléter ce cadrage. Les sources éclairent les responsabilités possibles, mais elles ne permettent pas de conclure que votre organisation dispose des moyens de les exercer.
Sources
Microsoft Learn : What is platform engineering?
CNCF TAG App Delivery : CNCF Platforms White Paper
France compétences : TP - Administrateur système DevOps
