Et il y a une bonne raison à sa résurrection : toute réalisation informatique qui implique plus d'une application est un cauchemar : coordination, construction à plusieurs, tests à plusieurs, stress à plusieurs...

Alors les solutions fusent, toujours les mêmes : il faut diminuer le nombre de boîtes et le nombre de fils entre les boîtes.

Deux erreurs néanmoins, la première : diminution du nombre de boîtes. L'urbanisme « vu d'en haut » produit autant d'aberrations que les décisions « vu d'en bas, le nez dans le guidon ». La logique de l'unique, du beau, rend souvent aveugle. La diminution du nombre de boîtes n'est pertinente que si elle s'accompagne d'un corollaire organisationnel : la sédentarisation d'équipes sur des novas. Urbaniser deux boîtes « Gestion de XX » en une seule et l'envoyer en TMA ne va rien changer à nos problèmes de productivité.

Diminution du nombre de fils, le fameux syndrome spaghetti : N applications communicant directement entre elles peuvent tisser N*(N-1) flux, pourquoi ne pas centraliser ces flux vers un tiers, et ainsi gérer une situation à N flux ? Là encore, le spaghetti n'est pas un mal en soi, bien au contraire. Vouloir centraliser la gestion des flux à n'importe quel niveau (le plus haut possible !) conduit à des situations ubuesques à l'inverse de l'effet recherché initialement.

Victime d'une vision statique de N*(N-1) « fils », nous éludons la réalité dynamique de construction de ces fils. Pour un projet informatique qui s'étend sur deux applications, la centralisation vers un tiers conduit désormais à coordonner trois interlocuteurs, la source, la cible et le tiers, et non plus deux comme au bon vieux temps ... Le cauchemar, dont la racine est la coordination d'équipes, a en fait été amplifié. Plutôt que de diminuer ou concentrer les flux, interrogeons-nous sur notre productivité à en construire et surtout à en maintenir.

Et c'est là que le bât blesse puisque la plupart des outils EAI, rebaptisés ou « étendus » en outils SOA, ne supportent pas encore les standards de productivité du build. En particulier le développement piloté par les tests et l'assemblage automatisé, supporté par des fondations J2EE ou .Net.

Or la nécessité de produire un SI toujours « plus intégré » va induire une plus grande pression sur les tests de ces programmes aux jointures de nos SI. Nos outils devront nous permettre de réaliser simplement la non-régression de centaines de flux suite à une maintenance sur un dictionnaire par exemple. La maturation des outils EAI doit se poursuivre dans ce sens, probablement aidée par leur fusion dans des Enterprise Application Platform (EAP) déjà soumises à ces principes d'ingénierie logicielle modernes.

Le demantèlement des territoires centrés sur la tâche (produire des cahiers des charges, produire du code, tester, intégrer ..) au profit d'une organisation centrée sur les applications, leur structuration sur un pattern royaume / émissaire qui sépare nettement les programmes d'échange du reste de l'application, sont des pré-requis à tout achat d'outils ou de conseils génériques destinés à améliorer « l'agilité du SI ». Côté technologie, on préfèrera comme d'habitude les choses simples aux usines à gaz multi-fonctionnalités "dont vous aurez besoin un jour"...