La charge ops cesse d'être une file d'attente le jour où les incidents, les changements et les décisions de capacité ont besoin du même contexte partagé et de la même automatisation. À ce moment-là, ce qui manque n'est pas un ticket de plus dans un backlog silencieux : c'est un endroit où l'état réel de la plateforme, les procédures et le nom du responsable existent avant la demande.
Ce que le modèle au ticket fait bien
Faire le procès du modèle n'apprendrait rien. Une file de tickets est un bon outil quand la demande est discrète, indépendante et traçable : un accès à créer, un certificat à renouveler, une alerte à qualifier. Elle donne un historique, une preuve de traitement et une répartition de charge lisible entre plusieurs personnes. Beaucoup de parcs vivent très bien ainsi, et rien ne justifie d'en changer tant que c'est le cas.
Le modèle a aussi un mérite contractuel : il rend la prestation dénombrable. C'est ce qui le rend confortable à l'achat — et c'est aussi ce qui se retourne contre tout le monde dès que les composants deviennent dépendants les uns des autres. Dans ce que couvre réellement un contrat de maintien en condition opérationnelle, le correctif se découpe très bien en demandes ; le préventif et l'évolutif, beaucoup moins.
Les trois moments où la file devient le problème
L'incident qui demande du contexte. Une saturation disque se traite en dix minutes. Une latence qui monte depuis trois jours sur un seul parcours utilisateur ne se traite pas du tout dans une file : il faut savoir ce qui a été déployé, ce qui a changé côté fournisseur, quelles limites de service sont proches et ce que la même panne avait donné l'an dernier. Rien de tout cela n'est dans le ticket. Si ce n'est nulle part ailleurs, chaque ticket redevient une enquête, et l'enquête recommence de zéro à chaque fois.
Le changement qui touche plus d'une chose. Une montée de version de moteur de base de données n'est pas une tâche, c'est une séquence : vérifier les dépendances applicatives, reconstruire un environnement de test conforme, jouer la bascule, savoir revenir en arrière. Découpée en tickets, la séquence perd ce qui fait sa valeur — l'ordre des étapes, et le fait que quelqu'un la tienne du début à la fin.
La décision de capacité. Redimensionner, engager de la capacité, éteindre les environnements hors production la nuit : ce sont des arbitrages, pas des demandes. Personne n'ouvre un ticket pour arbitrer. Le résultat est prévisible : la décision n'est jamais prise, l'empreinte reste celle du jour de la mise en production, et le sujet revient plus tard sous une forme que personne n'aime lire.
Le maintien en condition opérationnelle ne disparaît pas : il change d'unité de travail. Au lieu d'une demande traitée, l'unité devient un environnement décrit, une procédure exécutable et une vue partagée de l'état réel. C'est le rôle de BAM, notre plateforme d'exploitation : les environnements sont provisionnés as-code, les tâches répétitives du run — mises à jour, sauvegardes, redémarrages, extinction des environnements hors production — sont automatisées, et le coût, l'inventaire, la dérive et les écarts de configuration se regardent au même endroit.
La conséquence la plus utile n'est pas le temps gagné. C'est qu'une reprise après incident devient une reconstruction plutôt qu'une improvisation : l'environnement cible est décrit, donc reproductible. Et qu'un humain n'intervient que lorsqu'une décision est nécessaire, ce qui est précisément le travail qu'une file d'attente ne sait pas ordonnancer.
Les quatre différences qui comptent
- L'unité de travail. Le ticket compte des interventions ; la plateforme compte des environnements sous contrôle. Les deux peuvent être bons en même temps, mais un seul des deux chiffres dit si le système va bien.
- Où vit la connaissance. Dans le premier modèle, elle est dans la tête de la personne qui a déjà vu la panne. Dans le second, elle est dans le code qui décrit l'environnement et dans la procédure qui traite le cas. La différence se mesure le jour où cette personne est en congé.
- Ce qui se répète. Une file traite chaque occurrence ; une automatisation supprime la classe entière. Tant que la même demande revient toutes les semaines, l'exploitation est organisée pour la traiter, pas pour la faire disparaître.
- Le nom du responsable. Un backlog n'a pas de propriétaire, il a une profondeur. Un périmètre exploité a un interlocuteur nommé, qui doit pouvoir décider dans son périmètre sans convoquer un comité.
Elle ne remplace pas un périmètre écrit. La frontière entre l'infrastructure et le code métier reste à tracer, et c'est exactement là que les contrats mal rédigés produisent des allers-retours pendant que la production est arrêtée. Elle ne supprime pas non plus les demandes ponctuelles : il en restera toujours, elles continueront de passer par une file, et c'est le bon outil pour elles.
Enfin, elle ne dispense pas de réversibilité. Une plateforme d'exploitation qui rendrait le départ impossible aurait seulement remplacé une dépendance à quelques personnes par une dépendance à un outil. C'est la raison pour laquelle les environnements restent décrits dans un format que vous gardez, et documentés pour être repris par quelqu'un d'autre.
- Les mêmes trois ou quatre demandes reviennent chaque mois, et personne n'a de mandat pour les faire disparaître.
- Les délais de résolution sont bons, mais le nombre de tickets ne baisse jamais.
- Reconstruire un environnement de production supposerait une personne précise, et cette personne est la seule à savoir.
- Aucune décision de capacité n'a été prise depuis la mise en production, parce qu'aucune ne rentre dans le format d'une demande.
- L'état réel du parc — ce qui tourne, ce que ça coûte, ce qui a dérivé — se reconstitue à la main avant chaque comité.
Le bon moment pour changer de modèle
Ce n'est pas une bascule. Dans les reprises que nous faisons, l'ordre est presque toujours le même : décrire l'existant, automatiser d'abord ce qui revient le plus souvent, puis seulement rediscuter du contrat. Un forfait chiffré sur le périmètre — nombre d'environnements, criticité, couverture horaire — plutôt que sur un nombre de tickets n'a de sens qu'une fois cette première étape faite. C'est aussi le seul qui aligne les deux intérêts, parce que le prestataire n'est plus payé à proportion du nombre d'incidents.
Si vous hésitez encore, la question à poser n'est pas « combien de tickets par mois ? » mais « qu'est-ce qui reviendra encore le mois prochain, et qui a le droit de le supprimer ? ». La réponse dit à elle seule de quel modèle vous relevez.