Découvrez le monde des Systèmes d'Information

Dans les parties précédentes, vous avez découvert ce qu’étaient un système d’information et son écosystème au sein des entreprises, en particulier à travers la DSI. Vous l’avez sûrement bien compris, le SI est un élément central dans les entreprises, mais il est aussi très complexe.

Voyons cela en détail ! :)

Les raisons de la complexité du SI

Les différentes dimensions du SI

Vous pourriez judicieusement croire que ce sont les aspects techniques qui complexifient l’architecture informatique de l’entreprise. Et vous auriez raison... partiellement.

En réalité, la première raison pour laquelle un SI est en complexification croissante, c’est parce qu’il se trouve au cœur de l’activité de l’entreprise, au carrefour de 3 dimensions :

• La dimension technique bien sûr : le SI repose sur des matériels, des logiciels et des technologies qui permettent d’assurer les fonctions de base : collecter, stocker, traiter, diffuser.

• La seconde dimension du SI, c’est celle qui concerne l'organisation. Le couplage de l'organisation de l’entreprise et du système d'information est désormais très étroit.

• Enfin, le SI possède une dimension stratégique, car il accompagne l’entreprise dans le contexte économique concurrentiel dans lequel elle évolue. Par exemple, une société qui crée des partenariats stratégiques sans gérer l’interopérabilité de son SI avec ceux de ses partenaires risque de ne pas pouvoir exploiter pleinement ses nouveaux partenaires.

Un système en constante évolution : 5 générations de SI

Une autre raison majeure de la complexité des SI d’entreprise, c’est leur évolution dans le temps. La maturation progressive de la connaissance des utilisateurs et des dirigeants dans le domaine de l’usage du SI, et l’évolution des technologies de l’information et de la communication, ont favorisé l’apparition de 5 générations de SI, que le tableau ci-dessous récapitule.

Chaque étape de cette évolution est dépendante des états précédents, de telle manière que ces 5 générations de SI coexistent aujourd’hui au sein des organisations, et souvent au sein de la même organisation.

Pour résumer, la complexification du SI d'entreprise est principalement due à sa nature transverse (technique, organisationnelle et stratégique), mais aussi à sa lente maturation depuis les années 1960.

Les conséquences de la complexité du SI

L'hétérogénéité

La première conséquence de cette complexité grandissante est que les sociétés disposent d’un nombre d’applications de plus en plus important fonctionnant sur des systèmes différents, destinés à des utilisateurs de plus en plus variés, qui les utilisent depuis des plateformes matérielles de plus en plus diverses.

Au-delà de ces applications, l’entreprise possède souvent une multitude de bases de données fonctionnant avec des technologies différentes, plusieurs référentiels, sur des plateformes hétérogènes.

Le couplage fort entre composants du SI

La deuxième conséquence de la complexité du SI est le couplage fort entre composants du SI. Dans un SI, les composants interagissent les uns avec les autres, ce qui crée une dépendance directe ou indirecte.

Par exemple, l’impossibilité d’isoler certains composants de l’architecture pour les tester en raison des fortes interactions qu’ils entretiennent avec d’autres parties du système rend les opérations de maintenance et de conception difficiles pour la DSI.

Des conséquences financières, RH et en termes d’activité

En troisième lieu, la complexité croissante des SI d'entreprise a des impacts plus pragmatiques :

• entretenir et faire évoluer un SI complexe coûte cher (temps d’indisponibilité plus long lors de pannes, évolution plus compliquée à réaliser, etc.) ;

• utiliser un SI complexe coûte cher (formation des collaborateurs, illisibilité des processus métier, etc.).

Des conséquences dans le cycle de vie du SI

Enfin, cette complexité se traduit aussi dans le cycle de vie du système d’information de l’entreprise : de sa conception à son utilisation.

En phase de conception, les équipes d’ingénieurs font face à des besoins métier très hétérogènes. Dans une même société, les besoins des différents services ne sont pas les mêmes.

Par exemple, le service de la communication a besoin de mesurer les réponses de la clientèle ; les gestionnaires RH ont besoin d'analyser les heures travaillées par le personnel afin d’évaluer la rentabilité des projets ; le service Production doit être en mesure de gérer les stocks.

Pour répondre à ces besoins (que nous verrons plus en détail dans le chapitre suivant), les équipes de la DSI doivent mélanger différentes technologies, différents systèmes d’exploitation et de nombreuses applications hétérogènes, ce qui peut devenir un véritable casse-tête.

Au travers de la lecture de ce paragraphe et au regard des impacts de la complexification croissante des SI, vous aurez bien compris que les entreprises ont tout intérêt à mettre en œuvre des moyens pour la réduire.

Les moyens pour réduire la complexité du SI

Faire face à la complexité de la phase de conception

Concevoir un SI, c’est commencer à réfléchir à l’organisation qui sera mise en place en fonction des besoins et de la stratégie de l’entreprise. Nous l’avons vu, cette opération est complexe, car les besoins sont hétérogènes.

Les experts utilisent des méthodes qui permettent de structurer la démarche de conception, en partant du besoin jusqu'à la réalisation, afin de mettre en place un modèle ou une représentation visuelle du besoin. Il existe différentes méthodes de conception de SI qui coexistent et sont exploitées différemment selon les pays. Dans ce cours, je vous propose de détailler la méthode UML, qui est très utilisée dans l’industrie informatique de nos jours.

Utiliser la méthode UML

UML, que l’on peut traduire par langage de modélisation unifié, est un langage visuel constitué d’un ensemble de schémas, appelés des diagrammes, qui donnent chacun une vision différente du projet à traiter. UML nous fournit donc des diagrammes pour représenter l’architecture ou le logiciel à développer : son fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel.

Pour mieux appréhender comment UML est utilisé, prenons l’exemple d’une mairie qui a besoin de gérer les salles communales qu’elle met à disposition à ses administrés.

Dans ce schéma, on décrit visuellement le rôle de chaque acteur vis-à-vis d’une fonction (les ellipses avec le texte) que propose le système (le grand rectangle).

Un autre exemple vous permettra de voir comment on peut décrire avec UML un enchaînement d’actions pour décrire visuellement un processus. Ici, on va décrire la recette de la mousse au chocolat, :) miam !

Après le point de départ (rond noir), on réalise plusieurs opérations en parallèle (battre les jaunes et le sucre, faire fondre le chocolat et battre les blancs en neige), jusqu’à atteindre l’état final (point rond entouré).

Vous l’avez compris, l’idée ici n’est pas de faire de vous un expert de la conception de SI avec UML, mais de vous montrer comment on peut utiliser des techniques visuelles pour décrire le fonctionnement d’un SI.

Réduire la complexité du choix des architectures

Dans la partie précédente, nous avons vu comment les équipes de conception utilisent des méthodes de conception, comme UML, pour décrire de manière visuelle les besoins de l’entreprise.

Dans le cycle de vie des SI, après la conception, l’étape suivante consiste à mettre en place l’architecture technique qui permettra de satisfaire les éléments issus de la phase de conception.

Contrairement à la conception, il n’existe pas de méthode d’architecture. Aucune méthodologie n’a réussi à s’imposer, contrairement à UML pour la conception logicielle.

Nous avons vu qu’il n’y avait pas de recettes toutes prêtes. Les équipes chargées de l’architecture du SI utilisent plutôt des bonnes pratiques qui ont mûri sous l’influence de la culture de l’entreprise.

Parmi ces bonnes pratiques, on trouve :

• utiliser les normes reconnues dans l’industrie. Par exemple, UML, ou bien les standards OGC pour les Web-Services, appartiennent à ces normes ;

• réduire les dépendances entre briques du SI afin de construire un système évolutif et modulaire ;

• faire en sorte que tous les acteurs du SI (utilisateurs, concepteur des bases de données, développeur, etc.) travaillent ensemble sur les problèmes architecturaux. Par exemple, les entreprises peuvent adopter une approche DevOps. Elle consiste à harmoniser les relations entre les équipes de développeurs et celles de production ;

• les sociétés ont aussi la possibilité d’externaliser cette phase du cycle de vie du SI auprès de prestataires.

La réduction de la complexité dans la phase de production du SI : l’urbanisation

L’idée maîtresse pour réduire la complexité du SI est que la décentralisation est nécessaire.

Vous l’avez compris, les modifications globales du SI sont complexes, coûteuses et risquées. La résolution des problèmes doit donc être appliquée localement à chaque partie du système, et ainsi porter sur des sous-ensembles moins complexes. Cette décentralisation doit minimiser les interactions, les interdépendances et les couplages entre les parties, pour permettre cette action locale, autonome et adaptée au besoin.

On vise donc à construire un SI modulaire et évolutif en phase avec les nouveaux besoins de l’entreprise (nouveaux projets, nouvelles technologies, réingénierie des processus…). On atteint ce but par une démarche d’urbanisation.

La démarche d’urbanisation du SI

Dès le milieu des années 60, les systèmes d’information commençaient à se construire au fil de l’eau, par ajouts successifs d'applications et de structures de données, sans souci de cohérence globale. Les évolutions au sein de l’architecture venaient souvent de la direction informatique, indépendamment de l’évolution stratégique de l’organisation. Les entreprises se retrouvaient avec une sorte de patchwork d’éléments qui n’avaient pas de cohérence entre eux. Conséquence : les SI étaient désorganisés et incohérents.

Pour réagir à ce dysfonctionnement, dans les années 80, la notion d’urbanisation des systèmes d’information apparaît, en particulier dans le milieu bancaire. Comme il est utopique de penser tout reconstruire, à l’image d’une ville, le SI devait être en mesure de supporter des évolutions et réorganisations permanentes. Eh oui, tout reconstruire aurait été coûteux pour les entreprises.

Pour cela, le SI doit donc être évolutif, réactif, flexible, interopérable, mais également sécurisé. C’est là le but de la démarche d’urbanisation du SI.

Nous l’avons vu, l’objectif est de faire évoluer le SI, voire de refondre certaines parties, sans détruire l’existant.

Pour cela, on va intégrer de nouveaux composants (logiciels et/ou matériels) en exploitant les avancées technologiques dans un souci de cohérence générale, de réactivité et de flexibilité.

La démarche d’urbanisation recentre l’évolution du SI sur la stratégie et les besoins des métiers. Elle est basée sur un modèle de quatre couches ou visions successives du SI (métier, fonctionnelle, applicative et technique) répondant à 4 grandes questions : Pourquoi ? Quoi ? Comment ? Avec quoi ? 

• Pourquoi ? À partir d’objectifs stratégiques clairement identifiés, on identifie les processus métier qui doivent être mis en œuvre au sein du SI.

• Quoi ? Et Comment ? On va chercher à détailler le plus possible les fonctions et informations utilisées par les différents processus. On cherche à recenser les informations et cartographier toutes les activités de l’entreprise.

• Avec quoi ? On va détailler les applications et architectures techniques qui permettent d’implémenter ces fonctions.

Prenons par exemple l’entreprise Santé Services SARL qui fournit des services de rééducation physique et des soins à des personnes âgées. Afin de rester leader dans son domaine, la direction de la société a décidé d’informatiser les données médicales manipulées par le personnel soignant d'administration, qui représentent aujourd’hui des volumes considérables de papier.

Afin d’illustrer la démarche d’urbanisation, appliquons les 4 couches de notre méthode :

• Pourquoi (vision métier) : l'objectif stratégique est clair, améliorer les soins aux patients en instaurant une meilleure gestion de l’information. Les processus métier à mettre en œuvre pour obtenir un SI automatisé qui satisfait cette ligne directrice sont (entre autres) :

  • éliminer la manipulation de papier ;

  • intégrer les données dans une base de données ;

  • respecter les règlements liés à la conservation de ce type d’information.

• Quoi (vision fonctionnelle) : ici, on cherche à déterminer une cartographie des différents composants du SI. Pour notre cas, on pourrait imaginer :

  • un composant d’acquisition des données à numériser ;

  • un composant de stockage des données ;

  • un composant qui fixe les règles juridiques ;

  • un composant permettant aux soignants et services administratifs d’accéder à l’information.

• Comment (vision applicative) : on détermine ici l’ensemble des applications logicielles mises à disposition des différents utilisateurs. Dans notre cas, on pourrait imaginer :

  • une application Web pour les opérateurs qui vont numériser les données ;

  • un système de gestion de base de données MySQL pour les traiter ;

  • une application MediAid sur terminal dans les chambres des patients pour que les médecins puissent accéder à leurs informations de santé.

• Avec quoi (vision technique) : on décrit ici l'infrastructure technique sur laquelle seront déployés les éléments applicatifs. Dans notre cas, on proposera par exemple un réseau interne à l’entreprise avec un serveur Web hébergeant les applications Web, et un serveur de base de données sur un serveur Linux.

Cet exemple est très succinct, mais il illustre bien la démarche d’urbanisation. Comme vous pouvez le voir, cette méthodologie consiste à partir du besoin pour aboutir à l’implémentation technique. C’est ce qu’on appelle une démarche « top-down ».

Maintenant que vous avez vu comment le SI est structuré par l’équipe de la DSI, je vous propose, dans le chapitre suivant, de découvrir comment se réalise le choix d’infrastructure.

En résumé

• Un SI est un ensemble complexe, car il possède une dimension transverse technique, organisationnelle et stratégique. Il hérite également d’une lente évolution parfois mal maîtrisée.

• Les conséquences principales pour les entreprises sont l’hétérogénéité des acteurs, des technologies, des applications et des données. Le cycle de vie du Si de sa conception à sa mise en œuvre est également impacté par cette complexité. Par ailleurs, maintenir et faire évoluer le SI engendre des coûts supplémentaires (humains, financiers, de fonctionnement).

• L’idée maîtresse pour réduire la complexité est de rendre le SI modulaire et évolutif, grâce à une démarche d’urbanisation qui consiste à mettre en cohérence les impératifs stratégiques avec les architectures fonctionnelles, applicatives et techniques.