Le simplisme contre la simplicité

24 avril 2002

Un système d'information ne peut être réussi que s'il est aussi simple que possible sur le plan fonctionnel, car son coût est une fonction quadratique de sa richesse fonctionnelle. Cependant son architecture ne sera pas nécessairement simple : il est souvent difficile de décrire simplement la solution la plus efficace sur le plan informatique. 

Les décideurs, souvent trop tolérants envers les complications fonctionnelles, sont par contre aisément séduits par des architectures techniques qui leur paraissent simples. Ils font alors le choix du simplisme et non celui de la simplicité. 

J'en ai vu des exemples en ce qui concerne l'EAI (Enterprise Application Integration) et l'ERP (Enterprise Resource Planning). 

EAI (Enterprise Application Integration)

Les commerciaux des SSII disent que l'EAI résout les problèmes d'interconnexion des applications et les problèmes d'interopérabilité entre SI d'entreprises différentes (architectures d'entreprise étendue). Ils présentent à leurs client un transparent séduisant : "l'architecture du passé", où les échanges entre applications sont représentés par un fouillis d'arcs reliant celles-ci deux à deux, contraste avec "l'architecture de l'avenir" où les applications sont toutes bien proprement reliées à un "bus" EAI.

Cependant cette simplicité masque la véritable nature des EAI. La communication entre applications suppose en effet résolus des problèmes de physique, de logique. L'EAI ne dispense pas de cet effort. Tout au plus fournit-il, dans le meilleur des cas, des outils qui le facilitent.

Voici les plus importants parmi ces problèmes :

1) référentiel : si le codage des données n'est pas le même dans les diverses applications (c'est fréquent), il faut prévoir des transcodages pour faire communiquer celles-ci ; ces transcodages peuvent impliquer une perte de qualité des données - par exemple si l'on passe d'un code géographique à un autre dont les zones sont différentes, le transcodage automatique est approximatif ; un transcodage exact nécessite le traitement humain des cas douteux.

2) synchronisme : la chronologie des données d'une application mise à jour une fois par semaine n'est pas la même que celle d'une autre application mise à jour quotidiennement ou en mode transactionnel : on ne peut donc pas faire communiquer sans précautions ni corrections des applications non synchronisées. 

3) volumétrie : les solutions à retenir ne sont pas les mêmes selon le volume à échanger. Si le canal est trop étroit, les mémoires ("buffers") vont déborder et des messages seront perdus.

4) traitement des rejets : il faut définir le traitement (souvent en partie automatique, en partie humain) des messages que l'interface entre deux applications refuse.

5) concurrence : lorsque plusieurs personnes peuvent avoir accès en même temps au même dossier, il faut éviter que les modifications qu'introduit quelqu'un ne soient écrasées par des modifications qu'introduit quelqu'un d'autre.

Le fonctionnement d'un EAI suppose ces divers problèmes résolus. L'EAI n'est pas une "technologie", un "outil" qui les résoudrait de façon automatique, mais une démarche d'architecture assistée par des outils. On peut dire que l'EAI a la vertu de contraindre l'entreprise à résoudre ces problèmes ; mais il faut peut-être dire aussi que l'on aurait dû les affronter sans y être contraint par la mise en place d'un EAI.

Les bons EAI sont ceux qui comportent des outils documentaires ou autres assistant la solution de ces problèmes. Il faut donc, lorsqu'un fournisseur propose un EAI, l'interroger sur les fonctionnalités offertes. Quelle aide l'EAI apportera-t-il à la solution des problèmes posés par l'incohérence des nomenclatures ? par l'asynchronisme, la volumétrie, la concurrence, etc. ? La discussion devient alors précise ; elle se complique et l'on échappe à l'illusion de simplicité qui constitue l'essentiel de l'offre commerciale. 

Si le commercial vous dit que ces questions ne sont pas importantes, qu'il faut faire confiance à la technologie, être de son temps et aller de l'avant, cessez de discuter avec lui : il y a des chances que son offre ne soit pas sérieuse. Méfiez-vous toutefois, prenez vos précautions : il se peut qu'il aille voir votre supérieur hiérarchique pour dire que vous êtes rétrograde, que vous refusez le progrès, et celui-ci le croira s'il est séduit par la simplicité de la présentation !

Le problème est un peu le même qu'avec les EAI. Les fournisseurs suggèrent de rebâtir votre système d'information de sorte que les données soient placées au milieu des diverses applications et que celles-ci puisent dans le même stock. C'est en effet un excellent principe. Le malheur, c'est que lorsque l'on installe un ERP dans une entreprise il faut l'interfacer avec les applications existantes, modifier les processus de travail et changer l'organisation. Tout cela est coûteux. Si vous payez 2 M€ pour acheter les licences de l'ERP, vous devrez payer de l'ordre de 60 M€ pour le paramétrer, modifier l'organisation et lancer l'exploitation. Il faut avoir cette proportion en tête lorsque l'on évalue une offre. 

Parfois l'ERP sert à imposer à l'entreprise des changements que l'on n'a pas eu le courage de faire autrement. Chez l'un de mes clients le service "achats" était notoirement inefficace. Les 250 acheteurs passaient avec les fournisseurs des contrats que chacun gardait pour soi : si l'acheteur A avait passé avec le fournisseur F un contrat prévoyant un tarif dégressif, il gardait cette information pour lui et l'acheteur B ne pouvait pas tirer parti de la dégressivité. Il aurait été facile de mettre ces contrats dans une base documentaire partagée par les acheteurs ; cela n'aurait coûté que 100 k€ environ, mais cela demandait un courage que le directeur des achats n'avait pas. Pour résoudre ce problème, et traiter il est vrai d'autres problèmes de comptabilité, il a préféré acheter un ERP dont la mise en oeuvre a coûté plusieurs dizaines de millions d'euros et contraint à retenir une solution relativement inefficace pour la gestion des stocks.

Cette solution avait horrifié le directeur de l'informatique, le directeur de la logistique, la maîtrise d'ouvrage du système d'information ; mais le directeur des achats a eu gain de cause lors de l'arbitrage devant le DG : celui-ci n'a pas voulu désavouer un de ses directeurs (cf. "le compromis managérial") et en outre il a été séduit par la "simplicité" de la solution.  

En fait l'ERP est efficace pour des opérations banales, situées hors du cœur de métier. Pour votre cœur de métier, vous aurez besoin de fonctionnalités trop fines pour que l'ERP puisse les offrir de façon convenable. La gestion des stocks faisait partie du cœur de métier de mon client ; renoncer à son optimisation a dû lui coûter quelques dizaines de millions d'euros par an.

La simplicité de l'ERP, la simplicité de l'EAI sont purement nominales : c'est la dénomination qui est simple, non la chose elle-même. Ces dénominations sont comme le boîtier d'un ordinateur dont l'apparence parallélépipédique recouvre et masque un monstre de complication, une merveille d'ingénierie.