La gestion du système d'information

La vie d’un système

Le terme « système » représente tout ensemble cohérent de composants liés entre eux pour fournir un service à l’entreprise. Bien sûr, la première idée qui vient à l’esprit est qu’une application est un système. Dans le cas d’une application, nous allons rapidement être capables de faire une liste et regrouper les composants, par exemple, en documentation et programmes. Oui, il est possible d’être plus spécifique. Selon votre expérience, vous parlerez de documentation fonctionnelle ou de documentation technique ; pour les programmes, vous distinguerez différents types de programmes selon leur fonction ou s’ils sont développés en interne ou sont libres (libres voulant dire proposés par le/la ou les auteurs en libre accès). Tel M. Jourdain, en faisant ces regroupements, vous imaginez des configurations. Selon vos connaissances en informatique, vous regrouperez en programmes, en documents d’analyse, etc. Vous découperez le système selon votre expérience professionnelle, selon votre environnement de travail, car vous identifierez des groupes de composants différents. Admettons que vous soyez plus orienté infrastructure, plus serveurs et réseaux : vous vous dites qu’une application ne peut fournir ses services que si elle est supportée par un ou plusieurs serveurs et que les données stockées dans une ou plusieurs bases de données sont échangées via des réseaux.

Deux questions apparaissent : quels sont les groupes d’éléments que nous devons inclure lorsque nous voulons définir une application  ? Que devient la notion d’arrêt d’une application  ?

Rassurons-nous tout de suite quant à la première question : il n’existe pas une liste standard de groupes de composants qui définit une application. Tout dépend du contexte de la question. Nous retrouvons ici la manière et les choix à faire pour mettre en place le concept de configuration au sein du système d’information. Une application pour un informaticien qui développe va souvent être composée de programmes...

La vie d’un programme

Un système, avant d’être en production ou utilisé par l’entreprise, doit être créé. Un premier projet va créer ce nouveau système ou cette nouvelle application. Pour le projet comme pour le système, la notion de cycle de vie ne représente qu’une suite d’évènements, mais pour le projet, cette suite d’évènements ne se renouvelle pas. Un projet ne peut pas être considéré comme un cycle de vie, il permet seulement de contribuer à la vie du système.

Toute représentation d’un projet avec des boucles induit en erreur. Un projet est un ensemble d’activités qui s’enchaînent dans le temps. Il y a donc un début et une fin et, entre les deux, des jalons pour produire des livrables intermédiaires. Le livrable final est la somme des livrables intermédiaires.

Suivant la littérature, le projet inclut une première étape d’analyse. Celle-ci porte des noms différents selon les époques et les méthodes utilisées. Nous utiliserons le terme « analyse » dans ce livre pour les activités qui permettent de préciser et de comprendre les implications techniques, organisationnelles ou autres d’une demande utilisateur. Elle est en fait la suite de l’analyse rapide d’une demande utilisateur qui aurait été approuvée.

Nous avons donc la demande utilisateur (nous aborderons en détail la gestion des demandes dans le chapitre La gestion de programmes) qui est approuvée. L’entreprise est d’accord pour en savoir plus sur cette demande. La demande est analysée plus en détail, un peu comme une mise « pour voir » au poker : une mise « pro bet », une mise de sondage effectuée pour voir où l’on se situe exactement dans le coup et qu’elle est la réelle force de son ou ses adversaires. L’entreprise dépense un budget pour mieux comprendre la demande, les bénéfices, les risques, indirectement le positionnement par rapport à la concurrence. Ce budget pour voir est traité comme une dépense d’un point de vue comptable, qu’elle aboutisse...

Les différentes activités

Le bureau des programmes a normalisé les structures des activités planifiées globalement qui concourent à la création de systèmes ou à l’évolution de systèmes au sein du système d’information de l’entreprise. Mais il ne vous a pas échappé que la gestion du système d’information inclut d’autres activités, comme les activités de maintenance, les activités transverses, les activités administratives de gestion de chaque département et de la direction informatique elle-même et les activités de formation.

Les activités de maintenance concernent tous les éléments du système d’information, que cela soit des applications ou des serveurs, par exemple. Habituellement, les activités de maintenance comprennent :

La première catégorie est essentiellement celle qui permet au système de continuer à fonctionner conformément aux spécifications d’origine et comprend uniquement la correction de bugs, la correction de défauts de conception qui ont été détectés au cours des opérations, ou de nouvelles exigences spéciales qui peuvent être imposées par des organismes de réglementation ou de nouvelles politiques ou obligations de l’entreprise.

La deuxième catégorie (maintenance d’amélioration) comprend les modifications demandées par l’utilisateur après que le système a été déclaré opérationnel.

Pourquoi est-il important de préciser ce que contiennent ces activités ?

Une fois que le système a été développé et mis en œuvre, cela ne signifie pas la fin de l’implication du personnel de la direction du système d’information. Le système doit être maintenu tout au long de sa durée de vie. Rares sont les systèmes qui ne nécessitent pas une activité...

Le besoin de connaissance

De quelles autres informations a besoin le bureau des programmes pour gérer le système d’information ? Pour aider à gérer le système d’information, le bureau des programmes a besoin de connaître d’autres informations que celles des programmes. Il a besoin de les connaître, mais tout de manière générique. Il lui faut avoir la connaissance de la stratégie de l’entreprise, de la stratégie informatique bien sûr, des systèmes et de leurs composants, des ressources humaines et matérielles à disposition, des contrats, de données budgétaires.

C’est le minimum pour établir des tableaux de bord de suivi des programmes, certes pour le management, et suivre des indicateurs clés de fonctionnement.

Gérer le système d’information c’est gérer un portefeuille de programmes dans un environnement donné. Cet environnement comprend donc toutes ces activités. Pour les mener à bien, le bureau des programmes doit connaître les éléments du système d’information, les acteurs du système d’information, utiliser des métriques qui reflètent le fonctionnement du département du système d’information.

Les caractéristiques d’un département sont différentes de celles d’un autre département. Certes, nous essayons de nous comparer avec d’autres entreprises en prenant le même secteur d’activité, le même pays, les mêmes services. Pour cela, nous faisons appel à des comparatifs génériques de divers organismes. Ces données ne sont utilisées que pour information et en aucun cas comme cible. Cela pour deux raisons que nous venons de préciser, mais insistons : les entreprises sont différentes et les indicateurs ne sont pas calculés de la même manière.

Gérer un système d’information c’est d’abord se donner les moyens de comprendre l’organisation de son système d’information et de connaître les éléments...