Au lancement d’un projet informatique, bien que les coûts de maintenance et d’exploitation d’une application soient en moyenne 4 à 5 fois supérieurs à ceux de conception et de mise en oeuvre, les exigences et contraintes du run ne sont que très rarement prises en compte. Pourtant, dès son démarrage, le projet ne devrait pas se focaliser uniquement sur sa cible initiale mais bien s’attacher à rechercher le bon compromis entre les objectifs du build et les contraintes du run. Quelles conséquences sur l’organisation des équipes, notamment en charge du run ? Quels impacts sur le service délivré et sur l’efficacité des processus de run ? Toutes les compétences requises à l’exploitation du futur système sont-elles disponibles ?
Différentes contraintes à prendre en compte pour assurer le succès d’un projet
Tout au long de la vie du projet, la prise en compte des contraintes du run doit tendre à s’affiner au fur et à mesure que se précise la vision de la cible attendue. De cette analyse doit alors découler un plan d’actions permettant d’anticiper la future arrivée en production du projet et d’y préparer les équipes de run.
Cette attention est déterminante dans le succès d’un projet informatique et surtout dans la pérennité de son exploitation car c’est un prérequis indispensable :
- Dans l’identification des sujets centraux du transfert de connaissance vers les équipes de run ;
- A l’acquisition de toutes les compétences requises pour la bonne exploitation du futur système par ces mêmes équipes ;
- A la définition de modalités de « service management » claires et partagées.
Impliquer les équipes de run : clé de réussite du passage du build au run
Bien sûr, le passage du build au run se prépare à travers une bonne documentation du projet – et de préférence une documentation validée par les équipes d’exploitation –, par la définition et/ou la contractualisation de services auprès de l’exploitant, par l’implémentation d’une matrice de rôles et responsabilités claire et complète et enfin par la mise en œuvre progressive de processus de gestion des incidents, des demandes et des changements.
Cependant, le véritable succès de ce transfert des équipes de build vers les équipes de run réside aussi – et surtout – dans l’implication des équipes de run dès la phase de design du projet afin d’influer sur l’architecture du système, d’améliorer le coût de son cycle de vie et de prévenir les risques liés à son exploitation.
Mais comment impliquer les interlocuteurs du run dans le projet ? Sachant que les équipes de build et celles de run sont généralement issues de direction différentes. Qui est supposé diriger qui ? Qui est force de décision sur le projet ? À quel moment se fait la bascule du pouvoir de décision ?
Quelques bonnes pratiques de DSI pour mobiliser les équipes de run
Autrefois, la réponse d’une DSI à l’implication du run dans le projet passait par la désignation d’un ou plusieurs interlocuteurs privilégiés au sein de ces équipes de run. Ces « référents » avaient en charge d’assurer la coordination avec les équipes de build et d’acquérir dans le même temps toute la connaissance projet. Mais très vite, ces collaborateurs devenaient des points de contention, leur implication créant un problème de gouvernance récurrent : qui les pilote ?
Aujourd’hui, d’autres réponses émergent. Parmi les plus judicieuses, résident notamment :
- La création d’équipes projet « mixtes », composées autant de personnes venues du build que de personnes venues du run et détachées sous une direction unique ;
- La création d’instances de gouvernance autour de l’architecture impliquant à la fois les responsables de run et du build pour assurer la prise en compte des contraintes d’exploitation dès la phase de design du système ;
- La réalisation de Proof of concept (POC) pour éprouver les modalités de service management : l’ensemble de mon processus est-il clairement maîtrisé et connu de tous ? Les différentes parties prenantes sont-elles bien définies et en capacité de réaliser leurs actions ?. Ce POC permet également de faciliter la montée en compétences des interlocuteurs de run sur la prise de décision : quoi faire et dans quel cas ?
- La mise en œuvre de périodes probatoires à l’issue de la mise en production pendant lesquelles les équipes de run prennent progressivement la responsabilité du système tout en conservant un support des équipes de build ;
- La mise à disposition de socles normalisés portés par des offres de services standardisées permettant d’inverser le problème : il n’appartient plus au run de répondre aux exigences du build. Au contraire, il devient de la responsabilité du projet de s’inscrire dans les standards d’exploitation définis.
Quelles que soient les approches adoptées, celles-ci visent toutes le même eldorado : trouver le parfait équilibre entre objectifs du build et contraintes du run… et ainsi assurer la réussite totale du projet !
