Un système d’information d’entreprise est, dans la plupart des cas, composé de modules remplissant chacun une ou plusieurs fonctionnalités bien précises. Citons les fréquents modules suivants :
- La gestion de la relation client (CRM), dénommée à tort car il s’agit de gérer les prospects (qui ne sont pas encore clients par définition) et les opportunités associées
- La gestion commerciale permettant l’établissement automatisé de devis et la transformation en commande
- La gestion des catalogues de produits et services
- Le système de facturation (parfois directement associé à la gestion commerciale)
- La comptabilité
- Le système d’information des achats et du procurement
- Les systèmes d’information des ressources humaines (gestion du temps, registre du personnel, gestion prévisionnelle de l’emploi et des compétences, gestion des recrutements, paie, etc.)
- Le système de gestion des stocks
- Les annuaires (personnel interne)
- Le site institutionnel de l’entreprise
- Les systèmes de reporting et décisionnels agrégeant les données
- Les sites de e-commerce accessibles aux clients
- etc.
On le voit donc, au travers de cette première liste, un SI d’entreprise composé de nombreux éléments comporte naturellement une complexité d’autant plus exacerbée que chacun de ces éléments va interagir avec les autres.
Chaque composant peut être une partie d’un progiciel, un développement spécifique, mais à coup sûr ou disons dans 90% des cas, aucun SI n’est composé d’une solution unique couvrant tous les besoins fonctionnels.
D’où la nécessité d’interfaces, c’est à dire d’éléments autorisant la communication entre ces différents modules.
Prenons un module A et un module B, composants d’un SI, on peut avoir une interface « monodirectionnelle » A vers B (A envoie des infos à B), « bidirectionnelle » (A envoie des infos à B et réciproquement B envoie des infos à A). Voilà pour le sens des flux, par ailleurs il faudra considérer la dimension temporelle de ces flux :A envoie-t-il à B des données de façon périodique (par exemple une fois par jour, la nuit entre 3 et 4 h du matin, A envoie l’ensemble de ses données mises à jour depuis la veille à B), ou bien encore A et B échangent-ils de façon synchrone : dès qu’une information de A est ajoutée ou mise à jour, B en est immédiatement notifié et l’information lui est envoyée ? Ce caractère synchrone se mesure-t-il selon une latence exprimable en minutes, secondes, milli voire microsecondes ?
On voit donc plusieurs critères apparaître dans la définition d’un flux inter-applicatif :
- la (les) direction(s) des flux
- la temporalité de ceux-ci (périodicité/synchronicité)
- la nature des données transitant entre les 2 applications
- les évènements déclencheurs de transit d’information entre les applications (par exemple lors d’un ajout, une mise à jour ou une suppression d’une information dans A, B en est informé et l’information lui étant envoyé).
On comprend dès lors aisément toute la complexité de l’intégration d’un SI comportant, par exemple, une dizaine de modules. Si chaque module communique avec tous les autres, selon un flux unique, ce ne sont pas moins de 9+8+7+…+2+1= 45 interfaces qui sont potentiellement à mettre en œuvre !
Prenons un exemple concret aisément compréhensible. Imaginons un SI composé de 3 modules : un CRM (pour les commerciaux), une gestion commerciale permettant de faire des devis détaillés (avec catalogue de produits et services intégré) et un système de facturation. Voici un flux simple : le commercial identifie un prospect et une opportunité, il les saisit dans le CRM. Son prospect souhaitant recevoir un devis, une première interface permet au système de gestion commerciale de recevoir les informations relatives au prospect, sans que l’on ait à les ressaisir. Puis le devis est réalisé, et s’il est accepté, transmis par une seconde interface au système de facturation. On voit dans cette chaine simple deux interfaces : CRM vers gestion commerciale et gestion commerciale vers la facturation. Il est clair que le premier intérêt de la mise en place de telles interfaces réside dans le fait qu’il évite la saisie multiple d’information, ainsi ici, le nom du prospect saisi en amont dans le CRM, n’aura plus à être écrit de nouveau jusqu’à l’émission de la facture.
Se pose la question de la « vélocité » de ces interfaces. Peut-on accepter un délai d’une journée voire d’une heure entre la création d’un prospect dans le CRM et sa prise en compte dans le système de gestion commerciale ? Quel(s) est(sont) par ailleurs le(s) événement(s) déclencheur(s) de la transmission d’information ?
L’effet « spaghettiware »
On le conçoit aisément, l’intégration inter-applicative d’un SI constitue une des activités essentielles et réellement difficile de l’architecture informatique d’entreprise. Quand on a vu que pour 10 modules différents, il existe potentiellement 45 interfaces, on comprend mieux l’utilisation fréquente par les informaticiens du fameux mot « spaghettiware » : tel un plat de spaghettis, l’information circulerait au sein du SI au travers d’innombrables tuyaux enchevêtrés. Ce serait d’autant plus vrai que les SI ont une histoire et que, au gré de leurs évolutions, de nouveaux modules se sont greffés, avec leur lot de nouvelles interfaces …
Comment donc concevoir un SI simple, lisible, pleinement opérationnel, et évolutif ? Cela passe par une réflexion sur plusieurs axes:
1/ la définition claire des « datamaster », c’est à dire les systèmes qui sont référentiels pour chaque type de données
2/ les interfaces ne devraient servir qu’à transporter que les informations strictement nécessaires
3/ une analyse détaillée des flux, tant d’un point de vue du contenu transporté que des contraintes de temps de transport
4/ une harmonisation des technologies de circulation des informations (fichiers plats, API, middleware …)
5/ un effort proportionné dans le développement de l’interface en fonction des enjeux sur les données transportées selon plusieurs critères dont : le volume de données, et les délais acceptables pour les transporter.
Jean-Michel Lucas
©2018-2024
La transformation numérique des entreprises 