Interruptions en DSI : protéger le temps de projet

Le planning réserve la matinée à un chantier d’infrastructure. Un responsable passe demander une extraction, un utilisateur appelle directement son technicien habituel, puis un collègue cherche un avis. À midi, chacun a rendu service. Le chantier attend toujours.

Je ne commencerais pas par demander à l’équipe de mieux gérer son temps. Je regarderais qui est censé répondre pendant que les autres travaillent sur un projet. Si la réponse est tout le monde, la disponibilité affichée dans le planning n’existe pas vraiment. Voici l’organisation que je proposerais pour les sollicitations reçues pendant les horaires habituels de travail.

Relever les sollicitations qui échappent au planning

Avant de changer les habitudes, je proposerais une observation courte, sur une semaine de travail représentative. Ce serait un essai d’organisation, pas une étude de productivité individuelle. L’équipe noterait les demandes imprévues, leur canal d’arrivée, le besoin exprimé et le travail interrompu. Quelques lignes suffisent ; un relevé trop détaillé deviendrait lui-même une charge.

Je distinguerais surtout la demande nouvelle, la relance sur une demande existante et la question entre collègues. Elles n’appellent pas la même réponse. Une relance peut signaler un suivi absent. Une question technique peut nécessiter une discussion prévue. Une panne qui bloque une activité doit trouver immédiatement un interlocuteur capable de qualifier la situation.

Je chercherais aussi les interventions invisibles du DSI : promettre une réponse rapide dans un couloir, transférer un courriel sans priorité, demander une vérification pour une réunion. Ces sollicitations doivent apparaître dans le relevé au même titre que celles des métiers. Sans cela, on demanderait aux utilisateurs de respecter une règle que la direction informatique contourne elle-même.

Affecter un interlocuteur et retirer la charge correspondante

Je désignerais un interlocuteur pour accueillir les sollicitations sur une plage définie, avec un relais nommé en cas d’absence. Son rôle serait de comprendre le besoin, vérifier les informations utiles, traiter ce qui relève de ses compétences et orienter le reste. Il ne deviendrait pas responsable de résoudre seul tout ce qui entre.

Le chapitre de Google consacré à la gestion des interruptions décrit plusieurs modes de répartition et recommande de séparer les périodes consacrées aux interruptions de celles consacrées aux projets. Je retiens ce principe, sans reprendre le dimensionnement d’une équipe SRE pour une DSI d’ETI.

Dans le planning local, la plage d’accueil serait une affectation réelle. Je n’y placerais pas un livrable projet dont la réussite suppose une concentration continue. Les moments calmes pourraient servir à des tâches faciles à suspendre, sans les compter comme une capacité garantie.

La rotation devrait tenir compte des compétences et des contraintes de chacun. Faire tourner les noms à parts égales ne suffit pas si certaines demandes reviennent systématiquement au même spécialiste. Je conserverais un relevé des recours à ce spécialiste pour voir quelle disponibilité il reste réellement possible de lui réserver.

Définir quand interrompre une personne en projet

Je préparerais une règle lisible avec les responsables métier : quel contact utiliser, quelles informations transmettre et dans quelles situations attendre la réponse organisée devient impossible. L’utilisateur doit pouvoir expliquer ce qui est bloqué, pour qui, et quelle échéance est menacée. Il n’a pas à établir un diagnostic technique.

Le tableau suivant serait une base de discussion, à adapter aux activités de l’entreprise.

Je prévoirais un moyen de contact utilisable si le canal habituel ne fonctionne plus. Exiger un ticket depuis un portail inaccessible ne protège personne. L’interlocuteur peut enregistrer lui-même le besoin après avoir engagé la prise en charge.

Les horaires et les modalités de réponse doivent rester cohérents avec les engagements de service convenus avec les métiers. La rotation ne doit pas modifier silencieusement ce qui a été promis.

Organiser le recours aux spécialistes sans déplacer les interruptions

Le risque est de créer un simple standard : la personne d’accueil reçoit chaque demande, puis interrompt aussitôt celle qui sait répondre. L’utilisateur voit un intermédiaire supplémentaire et le spécialiste conserve toutes ses interruptions. Je définirais donc ce qui doit être préparé avant de solliciter un avis.

Une demande d’aide devrait préciser le symptôme, le périmètre touché, les vérifications déjà réalisées et la question à trancher. Pour une opération sensible, elle devrait aussi indiquer ce qui n’a pas été tenté. Je préfère une escalade explicite à une manipulation hasardeuse destinée à ne pas déranger.

Les questions qui peuvent attendre seraient rassemblées sur un créneau annoncé. Le spécialiste pourrait alors répondre, prendre la main ou demander un travail complémentaire. Pour un blocage qui exige son intervention immédiate, l’interlocuteur garderait le suivi du demandeur afin d’éviter que l’expert reprenne aussi toutes les communications.

À la relève, je transmettrais les demandes ouvertes avec leur prochaine action et leur responsable. Changer de personne à l’accueil ne doit pas obliger l’utilisateur à raconter de nouveau son problème. Je vérifierais également que les collègues continuent à échanger spontanément : une organisation qui rend toute question suspecte finirait par isoler l’équipe.

Limiter les engagements quand la capacité est dépassée

Le temps de projet n’est protégé que si quelqu’un peut décider quel travail attendra.

Je rendrais les demandes et les tâches projet en cours visibles dans un même suivi de capacité, même si elles restent gérées dans des espaces différents. Le Kanban Guide demande de définir explicitement comment le travail en cours est contrôlé. Une colonne supplémentaire dans un tableau ne suffit pas : il faut une règle pour décider quand démarrer une tâche.

Pour notre essai, je demanderais qu’une nouvelle sollicitation incompatible avec les engagements du jour déclenche un choix nommé. Quel travail est suspendu ? Qui prévient son demandeur ? Quand sa reprise sera-t-elle examinée ? La réponse ne devrait pas être laissée au technicien entre deux conversations.

Google recommande aussi, dans son chapitre sur la surcharge opérationnelle, de revoir la file de travail et d’identifier les tâches à différer ou à abandonner. Dans une petite DSI, je ferais porter cet arbitrage par le responsable qui peut réellement modifier les priorités.

Si le renfort devient quotidien, je présenterais aux commanditaires les conséquences observées : tâches reportées, besoins sans couverture et projets interrompus. Une réorganisation peut clarifier l’usage de la capacité disponible. Elle ne crée pas les compétences ou les heures manquantes.

Évaluer l’essai avec l’équipe et les demandeurs

Je lancerais le dispositif sur un périmètre connu, avec une date de bilan fixée dès le départ. La communication aux métiers tiendrait en un message concret : le contact à utiliser, les informations attendues et le moyen de signaler un blocage. Le DSI appliquerait lui aussi cette règle pour ses propres demandes.

Au bilan, je regarderais les plages projet effectivement tenues, les sollicitations restées sans réponse et les demandes revenues directement chez les spécialistes. Je demanderais à la personne d’accueil si elle a pu prendre ses pauses et terminer sa journée avec une relève claire. Protéger les uns en épuisant l’autre serait un échec.

Je ne comparerais pas les personnes au nombre de tickets fermés : accueillir, qualifier et résoudre correspondent à des travaux différents. Je chercherais plutôt les raisons des débordements et les ajustements possibles. Si les demandes sont mieux suivies et que les travaux prévus avancent, l’essai mérite d’être prolongé. Sinon, je modifierais le périmètre, la répartition ou les engagements avant de rendre la rotation permanente.