Bouge Ma Ville est désormais 100% gérée par API

Pourquoi nous généralisons l'utilisation des APIs à tous les services BougeMaVille ?

Nous avons décidé de promouvoir en priorité l'utilisation de nos APIs pour que les collectivités locales et les mairies puissent intégrer la solution Bouge Ma Ville encore plus nativement dans leur système d'information existant. D'ailleurs, la refonte des applications mobiles repose entièrement sur les API de Bouge Ma Ville.

Pour rappel, API est un service de bibliothèque de fonctionnalités, c'est une interface qui permet de se « brancher » sur une application pour échanger des données. Une API est ouverte et proposée par le propriétaire du programme. L'avantage est de pouvoir s'interconnecter à moindre frais avec un système client qui va pouvoir interagir avec cette interface.

En effet, dans beaucoup de cas, les villes ont déjà des applications mobiles pour smartphone qu'elles maintiennent, ou bien un site internet performant et moderne, qu'elles ne souhaitent pas remplacer. Et c'est tout à fait légitime, pour des raisons de coût et de stratégie. En tenant compte de celà, nous avons décidé de mettre en avant l'interopératibilité de notre service à travers un ensemble d'APIs et de Web Services afin de permettre aux mairies d'adopter notre solution sans démarrer un nouveau chantier. Cela peut se faire dans le cadre d'une TMA, d'une évolution aussi bien d'une application mobile que d'une page d'un site internet municipal.

Quel est l'impact du point de vue développement et intégration ?

L'approche par API est une solution pérenne pour les développeurs. D'une point de vue technique, il est bien plus avantageux de construire des ensembles, des blocs applicatifs dont les informations qui entrent et qui sortent sont sous la forme de services (API) plutôt que de construire un ensemble monolytique qui devra subir des évolutions mettant en danger la stabilité de tout le service. 

  • Evidemment, une API vous permet de construire un socle commun qui pourra être utilisé par plusieurs plateformes : dans le cas de Bouge Ma Ville, un site internet, une application mobile sous Android ou iOS (iPhone), un SMS/MMS, d'autres supports à imaginer, ... A chaque fois que vous faites des évolutions, toutes les plateformes en bénéficient, sans qu'il y ait besoin de redéployer autre chose que la partie du socle concerné.
  • La productité augmente car il y a moins de complexité dans la mise en oeuvre des évolutions ou des corrections. Il y a une vraie séparation entre le coeur de l'application et la diffusion et le traitement des informations, spécialement entre le front-office et le back-office. 

En résumé, l'utilisation des APIs permet d'améliorer et de faire évoluer un service avec plus de clarté, sur une architecture agile.
Mais qu'en est-il pour le client ? Est-ce que l'ouverture des API peut être bénéfique dès le début d'un projet ?

Quel est le point de vue du client (de la mairie, de la collectivité locale) ?

Et bien simplement, cela permet d'intégrer un service en étant "agnostique" de la partie traitement des données. On est "client" d'un service qui envoit/reçoit des données via l'API. Cela permet d'intégrer rapidement le service proposé sur les supports existants (application mobile, site web, ...) sans révolutionner ni refondre l'application connue des utilisateurs. Une page en plus (ou une page qui change), une icône ou un item en plus sur l'application municipale.

Pour rappel, les APIs sont utilisées aussi bien comme interface pour l'utilisateur (signalement ou rapport d'un problème) que pour le back-office (transmission d'un signalement à un logiciel, à un service technique ou à un système d'information de la collectivité).

Proposer directement une API a plusieurs avantages :

  • livraison du produit plus rapidement, évolutions du coeur de l'application sans avoir besoin de changer l'interface utilisateur (les écrans, les visuels)
  • les clients peuvent créer leur propre interface, leurs propres écrans à leur couleurs et en choisissant la présentation. Il sait quelles données devront être fournies via l'API.
  • une fois que c'est intégré, il n'y a plus besoin d'y retoucher, même en cas d'évolution du service (sauf évidemment s'il y a de nouvelles fonctions dans la bibliothèque de l'API).
  • L'interface proposée par la bibliothèque de fonctions peut être en messages pré-formatés, en XML ou en JSON suivant le cas. Ce sont des formats standards et donc facilement programmables.