Dans cet article


Offres d'emploi

Tags

Construire un SI Agile en 2020

Construire un SI Agile en 2020

Un SI Agile, c’est quoi ?

Définir ce qu’est un SI Agile, ce n’est pas une mince affaire ! Pour nous, voilà les quelques points récurrents essentiels sur lesquels se reposer :

  • Capacité à suivre les évolutions métiers
  • Facilité à maintenir (ce qui représente une grande partie du coût du système d’informations)
  • Facilité à faire évoluer
  • Sécurité
  • Stabilité

Globalement, si on devait se donner deux “règles” pour que votre système d’informations aille dans le sens d’un SI agile, ce serait les suivantes :

  • Garder les choses simples : inutile de se lancer dans une architecture complexe juste pour le plaisir
  • Une seule et unique application doit être responsable d’un type de données

Comment conçevoir un SI Agile ?

Dessiner un SI agile, de prime abord, ça ne semble pas très compliqué… mais la réalité est autre ! Dans la plupart des entreprises, on ne part pas d’une feuille vierge ! Le système d’informations a bien souvent un bon passif derrière lui, et c’est là que les choses se compliquent. Créer un SI agile sans tout bouleverser du jour au lendemain est encore plus complexe, puisqu’il faut à la fois garder une partie de l’existant, faire face à l’inertie des équipes et garder une vision long terme.

Peut-on définir des briques must-have dans son SI ?

Souvent, le constat tombe comme un couperet : il faut rénover le SI et construire un SI agile ! Mais, par où partir ? Peut-on distinguer des briques essentielles à prioriser ?

Généralement, on a envie de partir en ajoutant des fonctionnalités à son SI, en pensant que rajouter une brique va apporter de l’agilité et venir combler un manque.

Ceci est - à notre humble avis - la plus mauvaise idée. Si votre SI est bloquant, c’est avant tout qu’il est mal pensé. Ajouter une brique supplémentaire n’y changera rien, si ce n’est problablement de la complexité.

La bonne approche est avant tout de faire le tri dans l’existant et de vérifier qu’on a déjà de bonnes bases. Comme en architecture, si vous n’avez pas les bonnes fondations, tout l'édifice du SI manque de s’effondrer jour après jour.

Quelles sont les briques de base à avoir dans son SI ?

IDP - Identity provider

Basique et pourtant souvent oublié, l’IDP (identity provider) nous semble être la pierre angulaire du tout.

Un IDP permet d'évaluer l’identité d’une personne qui va inter-agir avec le SI. Ce peut être une personne interne à l’entreprise, un client, ou une autre partie prenante (fournisseur, partenaire, agent…) Tout ce petit monde va interagir d’une manière ou d’une autre avec le SI, l’IDP est là pour s’assurer que la personne est bien la personne qu’elle prétend être et c’est TOUT.

L’IDP ne doit pas avoir vocation à gérer des rôles, ou à remplacer votre gestion des habilitations par exemple, ce n’est pas son rôle. En effet, il faut bien garder en tête que, la gestion des rôles, des habilitations et ce que représente la personne pour vous, c’est une notion fluctuante et personnelle à chaque entreprise.

Il existe de nombreux IDP sur le marché, on vous conseille de préférer les solutions avec des protocoles ouverts, type OAUTH ou OpenID.

CIM - Qui est la personne pour vous ?

Une fois que vous savez avec certitude que Marc Dupont est Marc Dupont (grace à l’IDP), il faut maintenant définir ce qu’est Marc Dupont pour votre entreprise. Là, les choses se complexifient fortement… car Marc peut avoir plein de rôles ! Il peut être un client, mais aussi un fournisseur, un responsable d’une entité client et en même temps, responsable pour un autre client ! Oui, vous devez garder en tête que plus personne n’a un rôle unique et simple. Il faut donc se poser la question -pour vous et que pour vous- quels sont les rôles que Marc peut avoir. Ce travail est essentiel car il va permettre de gérer une bonne partie de la complexité du monde réel.

Il n’est pas possible de fournir une solution générique (c’est pas faute d’avoir essayer), il faut travailler avec les équipes et prévoir une solution assez souple.

C’est ce CIM qui va devenir le référentiel unique dans votre SI et qui va offrir l’information la plus à jour concernant Marc Dupont. Votre CRM (si un CRM existe dans votre SI) doit se baser sur ce CIM pour avoir une information à jour et pertinente.

Il est souvent nécessaire pour les entreprises travaillant en B2B d’avoir une ou plusieurs personnes dédiées à l’administration de votre référentiel. Et on ne le dira jamais assez, c’est le nerf de la guerre (et c’est normal) de maintenir ces informations à jour.

GED - Gestion de documents

De plus en plus de papiers sont dématérialisés… Si vous n'êtes pas vigilants, on se retrouve avec des situations dans lesquelles de nombreux documents sont stockés un peu partout dans votre SI et ça devient vite complexe de respecter les normes réglementaires et de stockage.

Dès le début, il faut poser la question d’une GED simple qui va juste faire son boulot de stockage et archivage des documents. Par expérience, on a envie de vous dire que la GED doit servir uniquement à stocker et archiver des documents et surtout pas à gérer des processus métier ! Parce que oui, c’est la mode en ce moment mais ça nous parait être une absurdité. Votre processus métier doit faire l’objet d’un logiciel adapté, le document n’est qu’une restitution et pas un processus métier !

Par exemple, établir une facture n’est pas la fin en soi du processus. Le processus est de facturer un client ! Le document n’est que la résultante. Donc s’il-vous-plait, utilisez la GED uniquement pour sa fonction première :)

Et après ? Quid de la suite ?

Si déjà vous avez correctement ces 3 briques dans votre SI, vous êtes capable d’adresser un des enjeux principaux du SI Agile, à savoir, laisser vos équipes travailler dans leurs applications métiers en respectant les standards de l’entreprise.

L’agilité va se créer naturellement en laissant l’initiative à chaque entité de votre entreprise. Quelques règles néanmoins peuvent être appliquées pour avoir un SI agile :

  • Une seule et unique application doit être responsable d’un type de données (Si votre CRM gère le relationnel client, alors tout le relationnel client doit être dedans!)
  • Considérer chaque application interne comme si c'était une application externe. Cette règle peut paraitre contre intuitive on vous l’accorde, mais elle est particulièrement efficace. Par exemple, votre service production décide de faire une application pour gérer un type de données. Vous pourriez les bloquer en essayant d’harmoniser les pratiques mais vous ne ferez que ralentir votre entreprise. Par contre, si vous définissez avec eux un contrat de service avec des points de passage obligés alors, vous maitrisez les données sur lesquelles ils travaillent et, si jamais vous souhaitez reprendre la main, alors il vous suffit de trouver un outil qui respecte ce contrat.

L'équipe AXOPEN

Voir aussi les articles suivants

Le rôle de l’architecture dans les SI

Le rôle de l’architecture dans les SI

Le 13/07/2010 par Philippe AUBERTIN

La comparaison avec le BTP : L’architecte système d’information conçoit l’architecture du système d’information, c’est-à-dire qu’il conçoit les différentes briques du système d’information (SI) et leur imbrication et est chargé de leur évolution. L’architecte système d’information est au système d’information de l’entreprise ce que l’architecte est à son bâtiment, si ce n’est que le système d’information est amené à évoluer plus fréquemment. Pour mener à bien sa mission, l’architecte système d’information doit en premier lieu étudier les besoins du client (sa direction ou bien le client chez qui il est en mission), établir une cartographie du système en analysant l’existant, puis proposer un modèle d’architecture et enfin la mettre en œuvre en choisissant une infrastructure matérielle et logicielle.
Lire l'article

Architecture des applications web en 2015

Le 04/10/2015 par Philippe AUBERTIN

Introduction Plus l’informatique avance et plus le choix d’une architecture web se complexifie. Faisons le point sur l’architecture des applications web en 2015. Un peu d’histoire sur l’architecture web Revenons d’abord un peu en arrière vers les débuts d’internet. A l’époque, il était très facile de choisir une architecture parmi les quelques technologies web existantes. Il suffisait en somme de choisir sa technologie serveur, soit in fine PHP ou Java.
Lire l'article

Qu’est ce qu’un virtual dataset sous Planisware ?

Qu’est ce qu’un virtual dataset sous Planisware ?

Le 18/08/2015 par Philippe AUBERTIN

Problématique Le progiciel Planisware comme la plupart des solutions de gestion de projets est destiné à traiter un grand nombre de données (tâches, affectations, dépenses, ressources etc…) ainsi qu’à réaliser des calculs en temps réel sur ces données. Planisware a donc mis en place des moyens techniques pour permettre des traiter et calculer ces données de manière performante et rapide : les Datasets et leur extension les Virtual Datasets. Mais qu’est-ce donc qu’un virtual dataset ?
Lire l'article