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


Comme toutes les grandes villes modernes, Saint-Etienne mène de nombreux projets dans le cadre de ce que l’on appelle aujourd’hui la Smart City. La ville a notamment répondu à l’appel à projet « Ville Durable » de l’Agence Nationale pour la Rénovation Urbaine (ANRU) en 2016. A cette occasion, la direction des Systèmes d’information et du numérique a noué un partenariat public/privé avec Suez pour la mise en place d’une plateforme Open Source en Open API : « notre objectif était de pouvoir nous adapter le plus possible aux flux de données issus de nos partenaires sur le territoire », résume Sébastien Valla, Directeur des Systèmes d’Information et du Numérique de la ville de Saint-Etienne. Et d’ajouter que « notre volonté était alors de nous placer en tant que chef d’orchestre de la donnée urbaine ».

Cette volonté se retrouve aussi au niveau de l’architecture interne du système d’information de la collectivité. Le DSI a en effet lancé un vaste projet de cartographie et de ré-urbanisation du système d’information, l’idée étant d’articuler les échanges de toutes les applications autour d’un bus applicatif.

Lors d’un atelier organisé sur le salon Ready For IT, fin mai, Sébastien Valla a levé le voile sur ce projet. Il a répondu favorablement à notre demande.

La genèse du projet remonte à 2014, alors que la DSI est confrontée au besoin d’intégrer ses flux RH. « Nous voulions que notre Active Directory soit immédiatement mis à jour en cas de départ d’un collaborateur », explique le DSI. « Désactiver les accès ainsi que tous les comptes d’un collaborateur qui quitte une structure est très important en termes de sécurité. C’est un gros sujet pour les RSSI et c’est précisément pour ce flux que nous avons entrepris le développement de notre bus applicatif ».

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-Etienne 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.

« 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 ce dernier ».

Sébastien VallaDirecteur des Systèmes d’Information et du Numérique de la ville de Saint-Etienne

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. mais elle entraine 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 coute que coute 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. 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 maitrise de nos SI que cette évolution entraine. C’est la raison pour laquelle nous avons souhaité nous doter d’un bus applicatif.

Une solution 100 % développée en interne

Après avoir mené une étude d’opportunité et évalué les solutions disponibles sur le marché.

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.

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.

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. 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. 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 ce dernier », 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. 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. commente Sébastien Valla. « Certains ont totalement compris ce changement d’approche et sont très partie prenante, 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…