« Spaghettiware»: de l’art difficile de l’intégration des composants du système d’information.

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

Publicité

Développement spécifique versus progiciel, ou comment réinventer la roue …

  Désireuse de s’équiper d’une solution informatique dotée d’un certain nombre de fonctions, une entreprise émet une expression de besoins, le plus souvent un « cahier des charges ».

Une question fondamentale -à mon sens- doit apparaître très vite : un progiciel, c’est à dire un produit de « série » proposant une gamme de fonctionnalités pourra-t-il répondre à ce cahier des charges, ou bien alors faut-il envisager un développement spécifique, c’est à dire un produit « sur mesure », totalement spécifié par le cahier des charges ?

Cette réflexion est réellement fondamentale pour l’entreprise à de nombreux égards, notamment :

A. Le coût total de la solution

B. La maintenabilité et l’évolutivité de la solution

C. L’adéquation fonctionnelle attendue

---

A. Le coût total de la solution

J’ai pour habitude d’utiliser une métaphore automobile pour comparer le coût potentiel d’une solution spécifique versus l’acquisition d’un progiciel.

En investissant pour un développement spécifique, le client demande un « prototype », une solution unique, qu’aucun autre client n’utilisera. En choisissant un progiciel, c’est comme si celui-ci choisissait un véhicule de « série », fabriqué en grande quantité, en usine.

On comprend mieux alors, au travers de cette analogie industrielle, la différence potentiellement drastique de coût entre les deux solutions.

Le raisonnement est simple. Imaginons la solution 1., spécifique, dont le développement coûterait 1 Million d’€. Cette solution sera vendue une fois et une seule au coût de 1,3 Million d’€ par exemple. 

Imaginons désormais la solution 2., progiciel dont le développement coûterait 2 Millions d’€. Si la solution est vendue 50 fois, il suffit de la vendre 2 x 2 M€ / 50 soit 80 000 € pour générer au total un revenu double du coût de production !

1,3 M€ dans le 1er cas …

80 k€ dans le second cas …

De quoi réellement s’interroger quant à la bonne alternative ! 

---

B. La maintenabilité et l’évolutivité de la solution

Une entreprise s’équipant d’une solution logicielle un tant soit peu élaborée le fait pour plusieurs années. Se pose donc la question du caractère maintenable et évolutif de la solution choisie. Quels sont les risques en fonction du scénario choisi ?

• progicieldépendance vis à vis de l’éditeur (« souveraineté numérique »)limitations quant à la « customisation » possible du progiciella « mitigation » de ces risques consiste à s’assurer de la qualité économique et technique proposée par le fournisseur (l’éditeur)s’organiser pour optimiser l’autonomie (configurabilité, connaissance intime du produit, transfert de compétences de l’éditeur au client)veiller au nombre de versions livrées par an, au nombre de clients de l’éditeur etc.
• choix d’une solution spécifique
  En 1997, je suis personnellement intervenu au sein d’une PME (électronique) qui avait fait réaliser une partie de son informatique de gestion (prise de commandes et facturation) par un indépendant qui lui avait « codé » une application spécifique. Résultat: trois ans plus tard, l’indépendant était occupé à tout autre chose, et le système se met à « bugger ». L’entreprise, qui avait tout de même pris soin de devenir propriétaire du code, se retrouve totalement bloquée, sans possibilité de générer la moindre commande ni la moindre facture. Je me souviens de plusieurs journées passées à trouver les fameux « bugs », en entrant dans le code qui avait été réalisé (non documenté bien sûr et absolument pas du tout maitrisé par l’entreprise). Indéniablement, choisir une solution spécifique et la faire développer, c’est prendre un risque important quant à la capacité d’assumer la maintenance corrective et évolutive de la solution.

La vocation même de l’éditeur est effectivement de proposer des produits qu’il fera évoluer, débuggera, et qui sont utilisés par plusieurs clients.

---

C. L’adéquation fonctionnelle attendue.

On marche souvent sur la tête dans ce domaine si l’on n’a pas bien compris l’importance de la dualité progiciel / développement spécifique.

On lit même bien souvent dans des cahiers des charges : « un développement spécifique ou une solution à base de progiciel pourront être proposés ».

De fait, le processus d’expression des besoins est – me semble-t-il – à reconsidérer:

Processus classique

1. Quel sont les besoins fonctionnels ?
2. Quelle ergonomie est souhaitée ?
3. Rédaction et émission d’un cahier des charges
4. Réception des réponses
5. Décision 
6. Lancement du projet

Le processus qui me semble participer d’une démarche optimisée: 

1. Quelles sont les fonctions offertes par les différentes solutions du marché ?
2. Quels sont mes besoins essentiels parmi ces fonctions ?
3. Rédaction et émission d’un cahier des charges orienté éditeurs
4. Choix de l’éditeur
5. Lancement du projet

Ceci me parait d’autant plus pertinent que 80% des besoins ne sont pas spécifiques à la société (ou organisation) cliente, mais communes à toutes les entreprises (ou organisations) du même secteur. Par ailleurs, il est bon de rappeler la fameuse règle des 80/20 : 20% des efforts risquent de représenter 80% du prix.

A quoi bon se restreindre à une description très spécifique et unique du besoin ? A quoi faire (il en existe encore) des maquettes d’écran ? A quoi bon croire que c’est le client qui reste décideur quant à l’ergonomie du logiciel ?

En conclusion : 

• soit le besoin est couvert à plus de 50% par un produit du marché, et il me semble alors totalement inefficace d’envisager une solution en « développement spécifique ».
• soit le besoin est tellement spécifique qu’aucun progiciel du marché ne le couvre. J’attends des exemples de ce cas là …  Je ne parle bien sûr ici pas du jargon, des sigles, des acronymes utilisés par le client mais réellement des fonctionnalités attendues.

Jean-Michel Lucas

©2018-2024

Pourquoi numériser ?

  Il est bon de retourner aux fondamentaux et de simplement tenter d’identifier les avantages de la numérisation (et la dématérialisation) des documents.

Imaginons un dossier de 5 000 pages, comportant des notes manuscrites, des plans, des diagrammes, des tableaux, une structuration (chapitres, sections, paragraphes). Composé de feuilles A4, à 5 grammes par feuille, notre dossier pèse 25 kilogrammes.

Quels sont les avantages d’une version numérisée de notre dossier ? Imaginons désormais que notre document soit disponible sous forme de fichier informatique.

1. Transport et accès : copié sur un disque dur externe, mon dossier ne « pèse » désormais que quelques dizaines de grammes. En y accédant via internet sur un cloud par exemple, je peux y accéder où je veux, quand je veux , sur un ordinateur personnel, une tablette ou un smartphone (lire mon article Pourquoi l’informatique est-elle « dans les nuages » ? )
2. Copie : en quelques secondes, je peux copier l’intégralité de mon dossier, pour un coût marginal. Je réalise autant de copies que je le souhaite. Une seule photocopie du document papier me coûterait environ 200 €.
3.  Diffusion : je peux partager mon dossier avec qui je souhaite en y donnant accès, en lecture ou en écriture, en quelques minutes. Envoyer une copie « papier » de mon dossier aux Etats Unis depuis la France me coûte 400 €, avec un délai de 2 à 3 jours. Déposer mon document sur un cloud et donner l’accès au document à d’autres utilisateurs ne prend que quelques minutes. Je peux également envoyer un lien vers le document par email en utilisant une plateforme sécurisée de téléchargement de fichier volumineux.
4. Sauvegarde : en copiant notre dossier sur un cloud et/ou sur un support externe, il est sauvegardé, à l’abri de tout incendie, intempérie, inondation, vol, usure (versus jaunissement et dégradation du papier).
5. Recherche dans le dossier :  en utilisant les fonctions basiques de recherche du logiciel de lecture du document, je retrouve en quelques secondes, des mots, acronymes, expressions, groupe de mots, ou des modifications apportées. Une utilisation plus avancée avec les techniques de LAD/RAD (lecture/reconnaissance automatique de documents) me permettent d’automatiser une partie des traitements que je souhaite effectuer sur la base des informations contenues dans le document.
6. Modification : je peux modifier mon document, le corriger, sauvegarder l’historique des modifications, collaborer en lecture et écriture avec d’autres personnes travaillant également sur ce document. Le travail collaboratif est extraordinairement optimisé.
7. Lecture : en quelques secondes je peux accéder, par exemple, à la page 2 758 de mon document de 5 000 pages. Je peux zoomer, dézoomer, adapter la mise en page afin que mon confort de lecture soit optimal.
8. Annotations, paraphes et signature: avec la version numérisée, plusieurs personnes peuvent annoter, parapher et signer électroniquement le document. La signature électronique a une valeur légale: depuis la loi n°2000-230 du 13 mars 2000, la signature électronique dispose de la même force probante que la signature manuscrite. L’article 1316-4 du Code civil prévoit en effet que la signature électronique est une preuve littérale au même titre qu’une signature manuscrite.
9. Correction et traduction : des correcteurs orthographiques et grammaticaux, voire des traducteurs automatiques sont disponibles. Bien sûr, rien ne vaut un travail humain pour finaliser une version correcte du dossier.
10. Rangement : Volume physique occupé = 50 cm * 21 cm * 29, 7cm = 31 185 cm3  pour le document papier.
11. Coût pour l’environnement : on produit environ 8 500 pages avec 1 arbre moyen.

Voilà donc quelques avantages qui illustrent l’intérêt de travailler sur des documents numériques. Ils sont nombreux et je vous propose de continuer à les recenser en commentant cet article.