Comment la ville de Saint-Étienne a revu et sécurisé son architecture applicative

Un bus applicatif pour reprendre le contrôle des flux

L’intérêt de remplacer des intégrations point à point entre applications est évident : un bus met fin à un plat de spaghettis d’intégrations qui devient vite ingérable. Et cela d’autant plus que le système d’information d’une grosse collectivité est extrêmement riche.

La ville de Saint-Étienne est l’une des 30 plus grosses DSI de collectivité territoriale de France et gère plus de 250 applications différentes. C’est deux fois plus que le périmètre moyen d’une entreprise privée.

Mais au-delà de cette problématique d’architecture, c’est la question de la maîtrise de la donnée publique qui est le moteur de ce projet. « La maîtrise de la donnée est un sujet particulièrement stratégique pour nous », explique Sébastien Valla.

« Nous avons face à nous de gros éditeurs qui nous imposent de plus en plus un hébergement externe de leurs logiciels. »

« Nous avons face à nous de gros éditeurs qui nous imposent de plus en plus un hébergement externe de leurs logiciels. Le modèle SaaS devient dominant et les nouvelles versions des logiciels ne sont souvent plus disponibles qu’en mode cloud. Or il s’agit de logiciels et de données qui peuvent être extrêmement critiques pour le fonctionnement d’une collectivité au quotidien. Les DSI doivent subir cette évolution du marché du logiciel, mais elle entraîne une perte importante de la maîtrise de nos données ainsi que du contrôle de leur sécurité ».

Si, depuis quelques années, de nombreux DSI ont essayé de maintenir coûte que coûte l’approche on-premise sur leurs données sensibles et critiques, cette approche est de moins en moins tenable. De plus en plus d’éditeurs ne proposent plus leurs solutions qu’en mode SaaS. C’est le cas du logiciel la gestion de courrier de la ville de Saint-Étienne, de même que la gestion des espaces urbains ou encore celle des marchés publics.

Le DSI explique sa démarche : « nous devions réagir face à la perte de maîtrise de nos SI que cette évolution entraîne. C’est la raison pour laquelle nous avons souhaité nous doter d’un bus applicatif, une couche logicielle intermédiaire qui allait pouvoir capter l’ensemble des flux qui entrent et qui sortent de nos systèmes d’information ».

Une solution 100 % développée en interne

Après avoir mené une étude d’opportunité et évalué les solutions disponibles sur le marché, le DSI fait le choix plutôt audacieux de développer ce logiciel en interne. « Nous disposions de compétences en interne pour le faire et nous voulions avoir une maîtrise complète de cette brique de notre SI et ne pas devoir nous appuyer sur un logiciel d’éditeur ».

Un autre facteur clé dans ce choix fut le coût des bus applicatifs commerciaux considéré comme beaucoup trop important pour une DSI telle que celle de la ville.

« Nous disposions de compétences en interne pour le faire et nous voulions avoir une maîtrise complète de cette brique de notre SI et ne pas devoir nous appuyer sur un logiciel d’éditeur. »

Le développement initial destiné à connecter la solution RH de la Ville à son annuaire Active Directory a représenté un effort de plus de 100 jours/homme. « Il s’agissait d’un effort significatif pour notre DSI », précise Sébastien Valla, « mais la plateforme est développée en mode objet, ce qui nous a permis par la suite d’industrialiser la connexion des nouvelles applications au bus ».

En parallèle un gros travail de cartographie du SI est engagé au moyen de la solution SOLU-QIQ d’AB software. « Nous avons entrepris de cartographier, mais aussi d’urbaniser notre SI : sur nos 250 applications, nous avons des points de jointures fonctionnelles entre elles. Sur un tel périmètre, nous avons fatalement une perte de maîtrise lorsque les chefs de projets s’en vont ».

Une unité en charge du patrimoine applicatif a été créée, avec un responsable de périmètre applicatif qui coordonne le travail avec le développeur, l’architecte et le référent applicatif côté DSI.

Le rôle clé du bus inter-applicatif

Dans cette démarche, le rôle du bus d’échange inter-applicatif est clé. Celui-ci capte les données sur les flux XML sur http/s et les convertis au format JSON. L’approche permet d’éviter toute modification aux applications internes. Tous les changements de formats sont réalisés au niveau du bus de sorte que lorsqu’une intégration doit être réalisée entre deux applications, il n’est plus nécessaire d’intervenir sur chacune d’elles, mais uniquement au niveau du bus lui-même. JSON constitue le format pivot qui permet de distribuer la donnée à destination de l’ensemble des applications sans devoir les modifier.

Une telle approche permet d’abaisser le niveau d’interdépendance entre les logiciels, susceptible de créer d’importants surcoûts. Uniformiser les formats et d’urbaniser le SI est un moyen pour la DSI d’éliminer ces surcoûts. « Le bus constitue aujourd’hui le socle de notre SI sur lequel viennent se placer nos applicatifs. Il n’y a plus de liens directs entre les applicatifs, toutes les données circulent via le bus ».

Avec son outil, la DSI peut superviser l’ensemble des accès au bus de données et le volet sécurité a été l’objet d’une attention toute particulière. Le bus applicatif a été déployé dans la DMZ interne et il est protégé par un pare-feu applicatif (WAF) qui analyse finement le contenu des flux de données. Les logs sont également surveillés. Cela permet de filtrer les accès par adresse IP et écarter d’éventuels flux malicieux. Tous les échanges sont chiffrés en http/s. L’ensemble de ces moyens permettent au DSI d’affirmer que le niveau de sécurisation de cette infrastructure est plutôt élevé.

Les éditeurs peinent à adopter l’approche API

« Notre but était de disposer d’une plateforme agnostique et de ne pas devoir imposer de formats techniques à nos partenaires ».

« Notre but était de disposer d’une plateforme agnostique et de ne pas devoir imposer de formats techniques à nos partenaires. Nous ne voulons pas perdre de partenaires pour des raisons techniques et ne pas avoir à renoncer à certaines solutions éditeurs pour des formats non supportés par ces derniers », résume Sébastien Valla.

Mais ce vœu s’est avéré plus complexe à être exaucé que prévu, car le niveau de maturité des éditeurs positionnés sur le marché des collectivités est très faible vis-à-vis de l’approche API. « Ce fut incontestablement la plus grosse difficulté pour nous que d’avoir à imposer cette capacité à tous nos éditeurs. Les éditeurs d’applications récentes, notamment d’applications mobiles sont généralement prêts, mais les éditeurs d’applications métiers très spécifiques le sont beaucoup moins. Pour un ERP, développer des API sur un logiciel existant qui compte de l’ordre de 500 processus demande un effort colossal de la part de l’éditeur. Certains le font, certains ont engagé une refonte complète de leur produit, d’autres pas. D’une certaine façon, nous nous privons de certaines solutions éditeurs à cause de cela ».

Désormais, la DSI indique dans ses appels d’offres et ses cahiers des charges que toutes les fonctionnalités majeures de la solution proposée doivent être accessibles sous forme d’API, au format JSON de préférence. « Il reste très difficile d’imposer cette approche encore aujourd’hui », commente Sébastien Valla. « Certains ont totalement compris ce changement d’approche et sont très “partie prenante”. Ils prennent parfois à leur charge certains développements, car cela entre totalement dans leur stratégie d’entreprise. D’autres restent toujours attachés à vendre un front Web et ne sont pas encore entrés dans cette culture de l’API ».

Actuellement, une centaine d’applications internes ont été connectées au bus de données de la ville, pour une dizaine d’applications externes seulement. Une indication sur le faible niveau d’externalisation de la ville, volonté affichée de la DSI, mais aussi des difficultés des éditeurs à basculer dans l’ère des API.