Pilotage applicatif
Comment faire vivre un domaine applicatif dans la durée - au-delà de la réaction au coup par coup.
Piloter
Vue d'ensemble plutôt que réaction au coup par coup.
Incidents
Disponibilité, SLA - et le déplacement côté SaaS.
Dette
Rendre visible l'obsolescence avant l'incident.
Indicateurs
Mesurer au-delà de l'absence de plaintes.
Le terrain
Une pratique qui se construit avec le temps.
Cadrage
Piloter un domaine applicatif
Avoir une vue d'ensemble du périmètre, plutôt que réagir uniquement quand quelque chose casse
Exploiter un domaine applicatif, c'est faire en sorte que ça fonctionne au quotidien : traiter les incidents, déployer les évolutions demandées. Piloter, c'est autre chose : c'est avoir une vision d'ensemble qui permet d'anticiper plutôt que de subir - savoir où en est chaque application du périmètre, pas seulement au moment où un problème remonte.
Ce n'est pas qu'une compétence technique. Piloter mobilise autant de compétences relationnelles et organisationnelles - faire remonter l'information, arbitrer, convaincre, choisir les bons indicateurs - que de compétences techniques. C'est ce qui en fait un exercice différent, et généralement moins immédiat à prendre en main qu'un sujet purement technique.
Disponibilité et incidents
Le service rendu tient-il ses engagements ?
Évolutions et dette technique
Le périmètre avance-t-il, ou accumule-t-il un retard invisible ?
Satisfaction métier
Les utilisateurs vivent-ils bien ce périmètre ?
Ce que ça change concrètement
- →Sans vue d'ensemble, on découvre un problème d'obsolescence ou une insatisfaction diffuse au moment où elle devient un incident ou une crise de confiance.
- →Piloter, c'est se donner des points de passage réguliers pour regarder le périmètre "à froid", pas seulement le jour où ça casse.
- →C'est aussi un exercice de communication - vers la hiérarchie, vers les métiers - pour rendre visible ce qui, sinon, ne l'est pas.
Service
Disponibilité et incidents
Le socle ITIL reste la référence - avec une nuance qui change beaucoup côté SaaS
La gestion des incidents (qualifier, prioriser, résoudre) et la notion de SLA sont déjà détaillées dans la fiche ITIL 4 - inutile de la dupliquer ici. Ce qui mérite d'être ajouté dans une logique de pilotage, c'est où se situe la DSI dans cette chaîne selon le mode d'hébergement.
Ce que le SaaS déplace
Sur une application on-premise, la DSI qualifie et résout - elle a la main sur l'ensemble de la chaîne. Sur une application SaaS, une partie du « résoudre » passe à l'éditeur ou l'opérateur : la DSI qualifie, transmet, et suit - elle pilote une relation de service plutôt qu'une intervention technique. Le pilotage devient alors le suivi des engagements contractuels (délais de traitement, disponibilité) autant que la résolution elle-même.
Piloter la disponibilité et les incidents, ce n'est donc pas seulement « combien de tickets », c'est aussi savoir, pour chaque application du périmètre, qui a la main en cas de problème - et si les engagements pris (par un éditeur, ou en interne) sont réellement tenus dans la durée.
Évolution
Évolutions et dette technique
Arbitrer les évolutions, et rendre visible ce qui vieillit en silence
Chaque demande d'évolution se pèse entre la valeur qu'elle apporte et la charge qu'elle représente - c'est le processus de changement déjà couvert côté ITIL. Le pilotage ajoute une dimension supplémentaire, plus difficile à faire remonter naturellement : la dette technique et l'obsolescence.
Ce qui constitue une dette technique
- →Une version qui approche de sa fin de support
- →Une dépendance ou une bibliothèque qui n'évolue plus
- →Une techno qui devient plus rare à maintenir, ou plus coûteuse à faire évoluer
Le piège de la dette invisible
Une application qui « marche encore » ne remonte jamais spontanément comme un sujet prioritaire - jusqu'au jour où l'obsolescence devient un incident (fin de support, faille de sécurité, impossibilité de faire évoluer). Piloter la dette, c'est la rendre visible avant qu'elle ne se transforme en urgence : la documenter, la qualifier, l'intégrer dans les arbitrages au même titre qu'une demande d'évolution métier - plutôt que de la découvrir a posteriori.
Mesure
Satisfaction métier et indicateurs
Savoir si un domaine est bien piloté, au-delà de l'absence de plaintes
C'est le pendant Check/Act de la roue de Deming appliqué à un domaine applicatif entier plutôt qu'à une action isolée : mesurer, pas seulement agir.
Des catégories d'indicateurs qui ont du sens
- →Disponibilité - le service rendu correspond-il aux engagements pris ?
- →Charge et nature des incidents - volume, récurrence, temps de résolution - une hausse silencieuse est souvent un signal avant-coureur.
- →Avancement de la dette et des évolutions - ce qui a été traité, ce qui reste en attente et depuis combien de temps.
- →Satisfaction métier - au-delà des tickets, un retour qualitatif régulier des utilisateurs référents sur leur vécu du périmètre.
Le risque à éviter
Un indicateur qui rassure sans rien mesurer d'utile - un « taux de disponibilité » calculé sans tenir compte des incidents vécus comme critiques par les utilisateurs, par exemple, peut afficher un chiffre excellent tout en masquant une vraie insatisfaction métier. Un bon indicateur de pilotage doit pouvoir changer une décision - sinon, ce n'est qu'un chiffre de façade.
Regard
Le regard du terrain
Un pilotage qui se construit avec le temps passé sur le périmètre - pas quelque chose qu'on maîtrise en arrivant
C'est probablement l'axe le plus difficile à investir en début de poste. La gestion d'incident se comprend et se pratique vite. La dette technique se documente en creusant. Mais le pilotage au sens large - avoir une vue d'ensemble suffisamment fine pour anticiper plutôt que réagir - demande d'avoir vu tourner le périmètre sur la durée : plusieurs cycles d'incidents, plusieurs campagnes d'évolutions, plusieurs retours métier.
Ce qui est réaliste à viser au début
Plutôt que de vouloir tout piloter finement dès l'arrivée, il est plus réaliste de commencer par cartographier ce qui existe déjà - SLA en place, dette connue, retours métier informels - et de construire les bons réflexes de mesure au fur et à mesure. Le pilotage n'est pas un état atteint une fois pour toutes, c'est une pratique qui s'affine avec le temps passé sur le domaine.
Le regard sur le pilotage applicatif
Piloter un domaine applicatif, c'est relier trois axes qui s'alimentent : la disponibilité tenue au quotidien, une dette technique rendue visible avant qu'elle ne devienne un incident, et une satisfaction métier mesurée au-delà de l'absence de plaintes.
Le SaaS déplace une partie de la résolution technique vers l'éditeur, mais pas le pilotage lui-même - suivre un engagement de service reste une responsabilité pleine et entière.
Et comme toute pratique de pilotage, elle se construit avec le temps passé sur le périmètre, pas dès le premier jour.
Piloter - vue d'ensemble
Incidents - service tenu
Dette - rendre visible
Indicateurs - mesurer utile
Le terrain - ça se construit