Dans un contexte économique difficile, accroître la fiabilité de la mise en production des applications représente un gisement d’économies souvent inexploité » annonce Pierre Audoin Consultants en septembre 2013, suite à l’enquête menée auprès de 50 entreprises et administrations. Face à cette préoccupation majeure des DSI qu’est la maîtrise des coûts, l’enquête fait ressortir un certain fatalisme de la part des entreprises interrogées par rapport à la qualité et in fine au coût engendré par ces opérations fréquentes et parfois complexes. Le cabinet PAC fait preuve dans ce document d’une vision claire de la frontière existante entre les études build et la production run, même si cela n’est qu’une partie du problème global. Il apporte aussi quelques pistes clés pour améliorer à la fois la préparation et l’exécution des mises en production, mettant en avant des bonnes pratiques sur l’outillage et en particulier sur le référentiel ITIL. Des pistes intéressantes que nous avons souhaité creuser davantage. Mais pour ce faire, il est avant tout nécessaire de faire un vrai retour en arrière sur la chaîne de valeur informatique. Nos recommandations feront quant à elles l’objet d’un prochain article.
Retour sur les 1ères organisations informatiques
Retournons 30 ans en arrière ! À cette période, les organisations informatiques se sont structurées en fonction de la chaîne de valeur de l’informatique de l’époque. Il s’agissait des applications « métiers » implémentées sur des systèmes centraux plutôt monolithiques et développées sur des spécifications répondant aux exigences « métiers » particulières à chaque entreprise. La réalisation de ces applications, leur maintenance et leur exploitation étaient organisées d’une façon séquentielle. Les cycles d’adaptation et d’évolution étaient assez longs. Le cœur du SI concernait le « produit », l’utilisateur accédait par un terminal « passif ».
La grande stabilité des applications et le côté « monolithique » des architectures centrales rendaient des opérations de mise en production assez simples, voire « mécaniques » et par conséquent plutôt fiables. Nous avons pu constater que la chaîne de valeur IT était alors naturellement industrialisée, sans qu’un effort particulier n’ait dû être fait. Par ailleurs, le faible nombre de fournisseurs et la prédominance d’IBM a largement facilité la tâche à l’époque.
ITIL : une solution pas forcément miraculeuse
Il est intéressant de rappeler que l’arrivée d’ITIL dans les années 80/90 coïncide avec l’émergence des architectures distribuées, rendant les mises en production plus complexes et faisant naître par la même occasion le besoin d’une formalisation des processus, pour retrouver une robustesse comparable. Toutefois la mise en production était alors restée une activité « technique » et par conséquent prise en compte par les techniciens de la production informatique. Ces activités étaient très loin des préoccupations des acteurs métiers… et les organisations IT et leur fonctionnement n’ont pas été mises en cause pendant longtemps.
Bien que proposée comme une solution clé par l’enquête PAC, la mise en place d’ITIL « pur(e) et simple », voire son implémentation « doctrinaire », peut aujourd’hui se révéler contreproductive car elle ne répond plus aux exigences d’agilité et de robustesse. En effet, la crise de 2008 et ses conséquences économiques ont mis à l’ordre du jour la question de l’efficacité de la mise en production.
Quelle réalité aujourd’hui ?
La généralisation des architectures « composites », l’arrivée de la « multi-canalité » et l’explosion du digital changent profondément la donne et mettent en cause les paradigmes du passé. Il faut l’avouer, les conséquences à venir dépassent largement le domaine des « bonnes pratiques » de la production informatique. Aussi, fort de cette compréhension du passé, LA question à laquelle il faut se soumettre est celle qui permet de trouver le meilleur équilibre entre l’agilité et la robustesse du SI. Pour le savoir, rendez-vous dans quelques jours pour une autre chronique.