Application maison : les avantages et les inconvénients

Une partie de mon travail quotidien au centre de services de SQLI est consacré aux applications internes, aussi appelées « applications maison ». Je vous propose un petit retour d’expérience sur les avantages et inconvénients de les privilégier par rapport à des applications du marché.

Lorsqu’un besoin interne est exprimé, les premières questions à se poser sont forcément :

  • Existe-t-il une application sur le marché qui couvre (totalement ou partiellement) le besoin exprimé ?
  • Quel est son coût ?
  • Peut-elle facilement s’intégrer avec notre SI déjà en place ?

Une fois cette étude réalisée, il est légitime de se demander si nous pouvons répondre à ce besoin via la réalisation d’une application maison en s’appuyant sur l’industrialisation, sur laquelle nous basons notre production pour nos clients et la force de frappe dont nous disposons. Et tout simplement car… c’est juste notre métier !

Application maison : les avantages sur le plan humain

L’avantage principal est d’avoir la main sur le produit délivré, du recueil du besoin à la mise en production. Ces deux aspects sont parfois compliqués (voire impossibles) à aborder via des « projets clients » (dans ces cas-là, notre interlocuteur est le plus souvent la DSI). Pourtant, ils sont très enrichissants sur le plan humain. Il en va de même pour l’interaction avec les utilisateurs ainsi que pour le déploiement et la formation. De plus, il est valorisant pour les collaborateurs, quelle que soit leur contribution sur un projet interne, de voir l’application sur l’écran de leurs voisins et de se dire : « Hey ! J’y ai participé ! ». Un de nos objectifs est d’ailleurs d’ouvrir, lorsque possible, le code source de certaines applications afin qu’ils puissent y apporter leur pierre à l’édifice s’ils le désirent (inner source).  

Les avantages sur le plan technique... et les INCONVÉNIENTS

Dans le cas d’une application maison, nous avons la main sur les technos qui seront utilisées. Le choix de ces dernières dépend bien entendu de divers critères comme le canal de diffusion (mobile, desktop) et des retours d’expérience. Il peut aussi être guidé par le souhait d’explorer telle ou telle nouveauté. Nous avons également la main sur l’industrialisation, du poste de développeur à la mise en production : c’est nous qui gérons. Ainsi, nous sommes libres de mettre en place les pipelines de livraison que nous jugeons nécessaires, et qui ne sont pas systématiquement réalisables avec tous nos clients :

  • Environnements iso (dev, intégration, recette, pré-production, production) grâce notamment à Docker. Le turnover sur ce type d'application pouvant être supérieur à la moyenne, cela permet aussi à de nouveaux développeurs de disposer rapidement d’un environnement de travail
  • Build et tests automatisés exécutés suite à un commit des sources
  • Déploiement automatique sur un environnement cible suite à un build réussi
  • Mise en place d’audits de qualimétrie via Sonar

Alors oui, tout n’est pas rose dans ce monde des applications internes. Parmi les inconvénients que je pourrais lister :

  • L’adhérence : en ayant la main sur le fonctionnel et l’aspect technique d’une application, nous pouvons avoir tendance à trop vouloir la faire coller à notre SI (et par effet de bord à la rendre trop dépendante de celui-ci). Cette tendance est évitée avec une application du marché ; à part quelques paramétrages toujours possibles, c’est au SI de s’adapter.
  • Les moyens mis en œuvre, en particulier en l’absence de roadmap claire et donc non budgétisée
  • La priorité (tout à fait compréhensible) donnée aux applications destinées à nos clients
  • La perte de connaissance fonctionnelle et/ou technique : des applications maison peuvent ne pas être modifiées pendant des mois voire des années. Il convient donc de mettre en place une documentation adéquate pour pallier ce problème.

Il est également parfois compliqué de fédérer le besoin exprimé par l’ensemble des utilisateurs, surtout lorsque des solutions diverses et locales sont déjà en place pour combler un manque fonctionnel. C’est pourquoi il est important d’avoir une gouvernance globale : un florilège d’outils peut entraîner confusion et désorganisation.  

Dans l’ensemble, c’est tout de même un plaisir de travailler sur ce type d’application : il permet de sortir de notre quotidien, d’avoir plusieurs casquettes (oui, les équipes sont en général composées de deux à trois personnes maximum) … et de contribuer au fait de ne pas être des cordonniers mal chaussés.