L’informatique d’entreprise a aussi ses habitudes. Pendant de nombreuses années, elle a fonctionné à base d’applications. Celles-ci constituaient le soubassement du système d’information, chaque application contenant sa logique métiers et les données appropriées, l’ensemble fonctionnant sur de gros systèmes informatiques.Les applications étaient couplées au coup par coup par l’intermédiaire de fichiers Batch. Cette situation aurait pu perdurer si les années 80-90 n’avaient été marquées par la crise et la mondialisation, poussant les entreprises à se réorganiser pour survivre.Elles ont donc analysé leurs processus de fonctionnement pour les optimiser, voire les repenser entièrement. La mode du BPR (Business process reengineering) était passée par là, ainsi que la croyance de pouvoir remplacer les vieilles applications monolithiques par de nouvelles architectures client-serveur.Toutefois, les problèmes de montée en charge et de consommation de bande passante ont limité la portée de ces architectures. Face aux exigences de flexibilité, il a fallu trouver le moyen de tirer parti des anciennes applications.L’EAI (Enterprise application integration) était née. Son premier objectif fut d’éviter d’utiliser des données déphasées entre les applications, en répliquant les données partagées ou en les groupant en un point central (entrepôt de données, par exemple). Dans un second temps, l’EAI a évolué pour faire interopérer les applications d’entreprise, celles-ci restant administrées de façon indépendante.L’apport de l’EAI a été principalement de faire prendre conscience aux entreprises de la nécessité de gérer les flux de données échangées entre les applications, avec la mise en place d’un urbanisme du système d’information. La vision de l’EAI était celle des flux, avec leur définition dans un référentiel central et leur supervision à partir de ce référentiel, grâce à des outils de trace adéquats. En revanche, toute vision de niveau métiers restait impossible.
Tous les niveaux d’encadrement de l’entreprise sont sollicités
Du BPR est tout de même restée la notion de processus métiers. Celui-ci prend en compte toutes les actions nécessaires au traitement d’une commande (par exemple, acquittement de réception, vérification de disponibilité du produit, expédition, demande de réapprovisionnement). Cette notion est transversale aux applications d’entreprise, chaque processus pouvant invoquer une ou plusieurs applications selon un cadencement défini.L’e-business poussant les entreprises vers toujours plus de réactivité, la notion de processus métiers a repris des couleurs en même temps que l’émergence des architectures de services. Dans ce modèle, on découpe les applications en plusieurs services de taille limitée, avec une fonction clairement identifiée, via des interfaces d’accès formelles.Ces services sont ensuite recombinés dans le cadre de processus métiers et font intervenir les différents niveaux d’encadrement de l’entreprise.
Retrouver tous les flux commerciaux échangés
La découpe des applications en services est un travail long et fastidieux. Dans la pratique, on encapsule la logique de l’application derrière des interfaces formelles d’accès qui définissent les services. L’accès aux services est alors réalisé soit par l’intermédiaire des logiciels d’EAI, soit par l’intermédiaire du protocole Soap (Simple object access protocol).Des outils de modélisation graphique peuvent alors recomposer la logique du cadencement des services à volonté. Stockée dans un outil de gestion des processus métiers, cette logique n’est plus incluse dans les applications, ce qui permet de la modifier rapidement, sans avoir recours aux informaticiens. De plus, les outils de gestion des processus métiers sont fournis avec des consoles d’administration permettant de superviser en temps quasi réel l’évolution des processus. Des outils d’analyse des processus commencent même à apparaître en vue d’améliorer leurs performances.La progression a été similaire dans le domaine de l’intégration B to B, entre les systèmes d’information des partenaires commerciaux. Dans un premier temps sont apparus des outils d’intégration des flux de données, dotés d’une supervision des messages échangés. Par rapport aux outils d’EAI, cette supervision est renforcée, car l’échange de messages prend une valeur légale vis-à-vis des passations de commandes.Les outils d’administration des solutions d’intégration B to B tels que ceux de WebMethods ou de Tibco doivent donc permettre de retrouver tous les flux commerciaux échangés entre les partenaires en direct ou par l’intermédiaire de places de marché, avec une garantie de bonne délivrance et de non-répudiation des échanges.Dans une seconde phase, des solutions de gestion des processus métiers englobant les outils d’intégration B to B au niveau des flux de données sont apparues pour donner une vision métiers des échanges. Arrivé parmi les derniers sur le marché de l’intégration B to B, Microsoft a ainsi retardé la sortie de BizTalk Server pour y intégrer des fonctions de gestion des processus d’échange regroupées sous le nom de BizTalk Orchestral.
Une administration qui reste simple
Ces outils de gestion des processus métiers B to B invoquent aussi bien les applications internes de l’entreprise, les serveurs d’échange de documents entre les partenaires commerciaux que des services Web trouvés dans des référentiels publics ou privés.Ces services Web sont plus particulièrement adaptés à un mode de fonctionnement de type requête-réponse (par exemple, la vérification de la solvabilité d’un fournisseur auprès d’un organisme de crédit). Leur administration reste simple tant qu’on se limite à un niveau d’invocation.En revanche, elle sera beaucoup plus complexe dans le cas de cascades d’invocations de services découverts dynamiquement. Le problème de la responsabilité du fonctionnement de l’ensemble de la chaîne pourra alors se poser avec acuité, nécessitant des outils d’administration nettement plus évolués.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
