Quand et pourquoi engager un diagnostic de son Système d’Information ?

Le Système d’Information est un point névralgique de l’entreprise : sa maîtrise est nécessaire tant pour son évolution que pour son maintien en conditions opérationnelles.

Chaque incident mineur ou grave sur le SI peut avoir de multiples impacts sur l’entreprise : son fonctionnement, son image, son résultat financier. Maîtriser son SI c’est être en capacité de diagnostiquer et corriger rapidement un problème.

Les transformations des entreprises sont de plus en plus fréquentes et transversales à l’organisation. Pour aborder une transformation du Système d’Information, définir une cible et une trajectoire il est nécessaire de connaître et d’analyser l’existant.  Cette tâche est d’autant plus complexe que la connaissance des SI Legacy s’est souvent érodée au fil des évolutions et des changements de personnel. 

Pour échanger sur les contextes dans lesquels sont réalisés les diagnostics du Système d’Information, nous accueillons Olivier Parker, porteur de l’offre AIT (Architecture, Intégration et Technologies) au sein de Projexion.

Qu’il y a-t-il concrètement derrière la notion d’audit ou de diagnostic du SI ?

Derrière la notion de diagnostic, il y a tout d’abord la connaissance. Impossible de faire un diagnostic sans une cartographie qui apporterait une vision, même synthétique, de l’existant.

Le diagnostic va alors porter un regard « extérieur » sur cet état des lieux en fonction de critères tels que des standards, des réglementations, des risques… Il va permettre aussi d’identifier des points forts et des déficiences de nature très variable : base de travail nécessaire pour initier une réflexion sur la transformation.

Dans la pratique, les diagnostics sont aussi souvent l’occasion de rattraper un retard de connaissance sur l’existant car celle-ci n’est pas actualisée, ou d’acquérir une connaissance plus approfondie du système d’information ! Bien sûr, dans l’idéal, il est préférable de maintenir cette connaissance dans le temps et d’être proactif. Fonctionner par à-coups, c’est prendre le risque de réagir trop tard ou de prendre de mauvaises décisions.

Les concepts de diagnostic et d’audit sont de mon point de vue très proches. L’audit a souvent une connotation réglementaire ou de comparaison à des standards. Le plus courant est de vérifier sa conformité avec la loi ou certaines normes, mais cela peut être aussi pour se comparer à des pratiques de référence du marché, ou par rapport aux enjeux et aux attendus du métier.

 

La métaphore médicale du diagnostic illustre bien l’idée ! Il est souvent mené en réponse à une « pathologie ». Et tout comme dans le domaine médical, cette pathologie aurait pu être identifiée en amont si le diagnostic avait été réalisé proactivement…

 

S’il existe quelques différences entre audit et diagnostic, ils se rejoignent donc sur les objectifs. Ils vont permettre d’acquérir une meilleure connaissance de son Système d’Information, de mettre en relief certaines facettes essentielles, d’identifier les risques et les causes d’incidents avérés ou probables, et de définir le plan d’actions pour y remédier.

Dans quels cadres sont généralement réalisés les diagnostics ?

Pour schématiser, il y a deux circonstances principales.

La première, est un diagnostic réactif. J’initie l’audit en réponse à un incident. Les causes peuvent être technologiques aussi bien qu’organisationnelles ou humaines. Ce n’est pas le cas le plus favorable !

Dans l’autre cas, l’entreprise est dans l’anticipation. Typiquement, elle veut engager une transformation plus ou moins importante qui a un impact sur son Système d’Information. Elle doit savoir si l’état actuel de son SI va lui permettre de supporter cette transformation et sinon quelles sont les étapes et les problèmes à résoudre. Le diagnostic sera une source, parmi d’autres, pour alimenter son plan de transformation et identifier la distance à franchir entre l’état initial et la cible à atteindre. Un check-up en quelque sorte !

Dans le monde idéal, les entreprises devraient mener à intervalles réguliers des diagnostics pour disposer d’une vision toujours actualisée de l’état du patrimoine IT. C’est le meilleur moyen de prendre à chaque instant les bonnes décisions. Dans la réalité, c’est le plus souvent par à-coups. Par exemple, l’entreprise réalise un diagnostic tous les 3 ans, à chaque nouveau plan stratégique. Entre chaque audit, le SI et les processus évoluent. Et lorsque le nouveau diagnostic démarre, la cartographie n’est plus à jour. Conclusion : entre chaque diagnostic, on prend des décisions à partir d’un état des lieux inexact.

 

Pourrais-tu nous partager les raisons principales de déclenchement de diagnostics au sein des entreprises ?

Oui, bien sûr. Le plus courant est le diagnostic mené à la suite d’un incident majeur sur le Système d’Information avec des conséquences visibles pour les métiers et l’entreprise. Indisponibilité, perte de données, cyberattaque… les risques sont de plus en plus nombreux ! Le diagnostic réactif est également engagé face à des problèmes récurrents qui représentent un coût réel pour l’entreprise, et pour lesquels une approche corrective ne suffit plus.

D’autres circonstances sont aussi à l’origine d’audits : par exemple si l’entreprise se retrouve contrainte par la complexité de son SI, qui la freine dans son développement, ou bien avant d’aborder une transformation afin d’évaluer la maturité du SI. Ou encore la recherche de leviers de performance, pour se comparer à un état de l’art, que ce soit par rapport aux concurrents, aux normes ou aux meilleures pratiques du moment. Il y a également le diagnostic d’adéquation avec les attendus métiers, c’est-à-dire la réponse ou non aux exigences métier. 

Dans les organisations qui ont développé des capacités d’architecture d’entreprise, connaître son existant est un prérequis à toute réflexion sur la trajectoire d’évolution !

 

Le diagnostic est un outil d’aide au choix ! Dans les plans pluriannuels, le diagnostic est un impératif. Les plans doivent se nourrir, entre autres, de la connaissance du Système d’Information.

 

Pourrais-tu nous présenter des diagnostics du SI que tu as vécus ?

Avec plaisir ! Un cas qui m’a marqué s’est déroulé au sein d’un très grand groupe. Un incident de production avait entraîné une interruption des services délivrés aux métiers. L’impact était énorme, et les services n’ont pas pu être rétablis dans les délais prévus. De plus, la DSI n’avait pas de convictions claires sur la cause, ce qui a accentué le signal d’alarme pour la direction. Impossible de définir un plan d’actions précis pour que cela ne se reproduise plus. Ils ont donc fait appel à un cabinet extérieur afin de mener un audit 360° à la fois sur les processus, les outils, l’architecture…  L’objectif était d’identifier la cause, et de comprendre pourquoi elle n’avait pas pu être identifiée en interne dans les échéances requises.

 

Ces circonstances sont de plus en plus courantes dans les contextes de cybersécurité. La direction se tourne vers la DSI en demandant : pourquoi le problème n’a pas pu être anticipé ? Quelle en est la cause ? Pourquoi nous n’étions pas prêts ? Et les réponses ne sont pas toujours là !

 

 

Un autre exemple assez emblématique était lié à un projet de transformation. L’entreprise avait engagé une grande transformation du SI avec une ESN de premier plan. Cependant, en 2 ans, rien n’était sorti. Le trou noir ! Ils avaient besoin d’un acteur extérieur pour comprendre pourquoi le projet n’avançait pas et quelles erreurs avaient pu être faites au niveau des processus, de la gouvernance ou des choix d’architecture du projet. Ce cas, avec des choix d’architectures complexes en début de projet, déconnectés de l’existant, n’est pas isolé ! Si l’entreprise ou l’ESN qui l’accompagne définit un objectif sans analyser l’écart par rapport au point de départ, la cible peut être inatteignable malgré tous les efforts ! 

 

Chez un acteur du retail, nous avons également mené un audit sous un angle différent. Il concernait le fonctionnement et la performance perçue d’une équipe IT. Le responsable avait pris conscience au vu des feedbacks des métiers qu’il fallait réagir. Son équipe avait l’impression de travailler d’arrache-pied pour répondre aux demandes, et pourtant les clients internes n’étaient pas satisfaits. Nous sommes intervenus pour poser un diagnostic de l’organisation, en particulier au travers d’interviews internes et externes à l’équipe et à l’entreprise. Quelle est la lettre de mission imaginée par l’équipe ? Quelles étaient les attentes des clients métiers ? Avec quelle qualité et quels délais ? Comment étaient-ils organisés pour honorer les objectifs ? Dans ce cas, nous avons identifié un écart entre les objectifs internes et les attentes externes, ainsi qu’un manque d’efficacité dans l’organisation et une insuffisance au niveau des outils et des processus. 

 

Pour conclure, quels sont les éléments qui peuvent faire l’objet d’un diagnostic ?

 

Ces exemples illustrent bien que le défi peut être technologique, mais il peut aussi venir des équipes, de l’organisation et des processus. L’entreprise peut être prête à passer au DevOps d’un point de vue technologique, mais pas d’un point de vue culturel car les équipes n’ont pas passé le cap de l’agilité ! Au niveau de la DSI, on peut également très bien avoir des équipes matures, des technologies de pointe, et des processus efficaces mais des équipes très mal outillées en termes d’ « IT for IT ».

Un diagnostic peut donc porter sur différentes dimensions :  technologie du SI, maturité culturelle, organisation et gouvernance, processus, SI de la DSI c’est-à-dire les outils de développement, de packaging, de test… 

Pour apporter quelques précisions, dans le cas d’un diagnostic d’architecture fonctionnelle et data, certains éléments analysés seront spécifiques. La structure du SI est-elle modulaire ? Les responsabilités « data » sont-elles claires ?  Y-a-t-il des recoupements fonctionnels d’applications ? L’architecture du SI est-elle ouverte sur l’extérieur ? Est-elle évolutive ?

Pour un diagnostic d’architecture technique par exemple, le prisme sera plus technologique. Les conditions d’exploitation permettent-elles une qualité de service satisfaisante pour les métiers ? Les choix technologiques sont-ils pérennes et compatibles ?  Quel est le niveau de disponibilité offert ? La sécurité du Système d’Informationest-elle sous contrôle ?

Si le diagnostic porte sur les organisations en charge de la maintenance du Système d’Information, l’auditeur s’intéressera à la définition des rôles et des responsabilités, à la documentation des processus, à la traçabilité des actions ou à l’outillage des équipes IT.

Si chacune des dimensions sera plus ou moins importante suivant l’objectif du diagnostic, il ne faut cependant pas cloisonner. L’intérêt du diagnostic est d’avoir approche holistique et d’identifier les impacts et les causes au-delà d’un prisme restreint !

 

Dans un article complémentaire, nous poursuivons ce sujet autour de la démarche et des facteurs clés de succès des diagnostics et audits du SI.

 

Olivier Parker, Consultant en Architecture d'Entreprise et management de Projet

Olivier Parker

Consultant en architecture d’entreprise 
et management de projets

 

Projexion est un cabinet de conseil en transformation des organisations. Notre capacité à mobiliser des expertises variées (architecture d’entreprise, gestion de projet, accompagnement au changement…) est un atout pour appréhender globalement les audits. En tant d’acteur de la transformation, nous pouvons vous accompagner de la réalisation du diagnostic IT jusqu’à la modification effective de l’organisation ou du Système d’Information !

Envie d’en savoir plus sur nos prestations d’audits et de diagnostics du SI ? Echangeons 

Soyez averti(e) de nos prochains évènements et publications via LinkedIn !