Logiciel d'urbanisation du Système d'Information dans le secteur Public (Collectivités locales)

Bonjour,

Je suis à la recherche d'une plateforme d'urbanisation du Système d'information dédiée au secteur public.

J'ai déjà vu quelques offres logicielles comme celle de Blueway (au travers du témoignage de la Région Bretagne), ainsi que de Talend, mais je souhaiterai ouvrir le panel de solutions et ma vision de ce qui existe, en particulier au niveau des offres dédiées aux Collectivités Locales.

-> Pourriez-vous svp me partager les logiciels que vous utilisez pour l'urbanisation du SI (type ESB) et la gestion des processus (type BPM) ?

Voici le lien du témoignage de la région Bretagne sur la rationalisation de leur SI en question que j'ai trouvé un intéressant pour ceux qui cherchent des retours d'expérience.

Merci d'avance !

Bonjour

J'avoue que je ne comprends pas bien le sens de plateforme d'urbanisation du Système d'information dédiée au secteur public.

Les outils que tu site n'ont pas grand-chose à voir avec l'urbanisme des SI

Si ce que tu cherches ce sont des outils qui permettent de faire en sorte que l'ensemble des applications du SI interagissent dans le but de répondre au plan d'urbanisme
Il n'y a rien de spécifique au service public.
Pour ma part j'utilise Servicemix (mais n'importe quel EAI/ESB ferait l'affaire) pour intégrer environ 10 000 applications dans le SI.

l'approche que nous avons mise en place est que toute application du SI ne communique pas avec une autre application mais avec le SI lui-même
C'est une façon de voir le SI. Mais elle impose aux différents projets du SI à réfléchir interaction globale et non pas tuyauterie entre applis.

Notre médiateur (servicemix + quelques autres outils) est là pour présenter à chaque application une abstraction du SI tel qu'il est défini dans le plan d'urbanisme. L'application n'a donc pas à savoir quelle solution a été retenue pour implémenter telle ou telle partie du plan d'urbanisme.

J'ajoute que nous avons fait appel à un très grand nom en 3 lettres de l'informatique pour nous fournir un tel outil que la solution proposée demandait des machines démesurées en grand nombre pour faire fonctionner ce qui était que le premier pas dans cette direction c'est a dire 1/500e de la cible. Le coût en millions d'euros nous a conduits à évaluer et lancer d'autres marchés. Aucun acteur du marché n'a été à la hauteur. Nous avons décidé de le faire nous-mêmes. Avec une équipe de 5 et 10 prestataires il a fallu 2,5 ans pour arriver au résultat. Nos 10 000 points de présences s'échangent environ 10 000 000 de message par jour sur environ 200 types d'échanges en temps réel accompagné d'environ 500 types d'échange chorégraphiés.

Le système fonctionne depuis maintenant 8 ans. Il n'avait jamais été arrêté. Nous avons changé de machine il y a 2 ans sans arrêter le système.

Le système de médiation n'est donc pas une plateforme d'urbanisation, c'est un outil parmi tant d'autres pour contribuer au plan d'urbanisme.

Souvent les outils comme Talend, Petalink, ServiceMix, Fuse, Mule, etc. sont utilisés associés à une application. Ils servent alors à prendre en charge pour l'application tous les problèmes de production et d'intégrations de données et de services.

Le point qui a radicalement changé chez nous c'est d'avoir inversé l'approche.
Nous avons un outil central qui représente une abstraction du SI et chaque application échange avec SI à travers lui. Chaque application n'a alors connaissance que de ces propres spécificités et du SI abstrait. Jamais elle n'a à savoir quelle technologie porte quelle fonction. Ainsi si une partie est remplacée le reste du SI ne s'en aperçoit pas.

Mais ça change surtout la façon de penser une application.

Par exemple lorsqu'une commande de produit est passée, il faut envoyer les infos au service compta, le détail de la commande aux magasins, etc. ce qu’il est l'approche classique de penser les communications dans une application.
Là, lorsqu'on fait une commande, on envoi les infos au SI à lui de ce débrouiller avec. Il faut donc réfléchir au fonctionnement global du circuit commande livraison et ses interactions avec les autres métiers.

Donc si tu cherches un outil d'Intégration d'Entreprise EAI/ESB nous n'en avons retenu aucun ni Talend ni Fuse, ni PetalLink (qu'avait retenu a la DGME avant de l'abandonner), ni oracle ESB ni WPS.
La raison est qu'aucune solution ne permettait de gérer simplement la taille et la diversité de notre SI.

La majorité de ces outils sont bien faits et faciles à mettre en oeuvre dans le cadre d'une PME comme Renault.
La boutade est volontaire. Dans un SI en général on a 1 appli RH 1 appli compta 1 appli gestion de stock 1 appli de, etc.
Chez nous notre besoin est de designer une fois est de déployer à très grande échelle. Nous avons une multitude de logiciels pour chaque secteur d'activité et il n'est pas question qu'une personne passe son temps entre 50 logiciels parce que chaque petit bout de son activité est porté par l'un ou par l'autre. Les acteurs sur mon secteur d'activité freinent tous l'approche service pour proposer des solutions en silo avec l'espoir qu'ainsi ils grignoteront tout le SI ce qui est impossible car aucun n'est capable de couvrir tous les besoins. Donc pour un métier donné si une application silo est son outil de travail alors c'est au SI de faire en sorte que s'il y a un module de commande livraison dedans il s'intègre dans le circuit. C'est comme ça que nous avons pour beaucoup de problématique métier un ensemble de logiciels répondant partiellement au besoin.

Au vu de tout ça il nous a fallu faire des choix. Et après toutes nos évaluations nous avons constaté que les 3 solutions qui étaient le plus proche de notre besoin en termes de capacité de monté en charge, de robustesse, de diversité et de rapidité étaient toutes basée sur Apache Camel la solution la plus souple était Fuse mais à l'époque elle embarquait des technos qui nous était inutiles (consommatrices de ressources) du coup il nous fallait détricoter le truc.
Si on avait retenu l'un des trois nous aurions été contraints par les contrats commerciaux et nous n'aurions donc pas pu toucher au coeur du produit. Nous avons donc choisi de revenir à la source de Fuse en utilisant la version libre ServiceMix que nous avons complètement réassemblée pour qu'il colle exactement à notre besoin.
Donc au lieu d'avoir un Servicemix un Talend ou petalLink payant ne correspondant pas à notre besoin parce que l'éditeur n'assure le support que si on y touche pas. Nous avons un servicemix qui possède les composants dont nous avons besoin, et que les composants don nous avons besoins.

Un point important nous avons des échanges avec SAP. SAP propose une librairie Java pour écrire des applis qui communique avec SAP.
Talend, tout comme les autres, IBM entre autres, nous ont proposé dans leur solution un connecteur à plusieurs centaines de milliers d'euros.
Nous avons mis quelques jours à développer un composant Camel donc totalement réutilisable basé sur la Lib de SAP. Manque de bol la licence SAP nous empêche de partager ce composant.

Si donc ton problème est bien l'intégration de donnée et service au sein du SI des outils comme Talend, Petal, Mule Servicemix Fuse sont faits pour ça.
Talend est très bien outillé et tend à faire croire qu'on peut le mettre en oeuvre sans connaissances. Mais il est très cher ou limité dans sa version gratuite. Petal a été abandonné par la Direction de la Modernisation de l'État pour son manque de capacité à assure un support à très grande échelle.
(On assure pas le support de tous les établissements de l'état avec 3 personnes.) Mule nous est apparu simple mais justement trop simple. ServiceMix Fuse sont équivalent libre ou supporté.
Camel est un framwork très riche ouvert et une fois qu'on l'a pris en mains très faciles à faire évoluer.

Faire son propre assemblage de Karaf Camel est très simple c'est la base de Talend, PetalLink, Servicemix/Fuse.
Le couple Karaf Camel permet d'avoir une solution souple évolutive robuste extensible.

A+JYT