Un SI Agile, c’est quoi ?

Définir ce qu’est un SILe SI désigne le système d'informations d'une organisation. 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.