Le point de vue qu’une organisation aborde sur les applications de son système d’information est révélateur de ses principes et fournit un excellent indicateur de la performance des pratiques autour du système d’information.
Aussi une question aussi simple « Et pour vous, qu’est-ce qu’une application ? » peut tirer beaucoup de fil.
Une application n’est pas seulement un amas de code. D’autres dimensions existent pour l’appréhender :
- La portion du plan applicatif
- L’emprise sur les environnements
- L’objet d’unité organisationnelle
- L’élément d’imputation de budget
- L’outil de création de la valeur métier
- Le nœud du graphe de flot de données
- La maison de la donnée
- L’œuvre d’un savoir-faire technique
- …
Les dimensions de l’application
Pour chacune de ses dimensions, on peut avoir un point de vue restrictif ou élargi.
Portion plan applicatif
Le périmètre de l’application est-il défini pas les composants en charge de manipuler et stocker la donnée pour laquelle l’application est responsable ? Inclut-on les éléments d’accès (CDN, Load Balancer, WAF, API Gateway) ? Inclut-on les connecteurs ou les demi-flux permettant à l’application de communiquer avec le reste du SI ? Le reporting opérationnel fait-il aussi partie de l’application ? Derrière ces questions, se pose celle plus générale du cadre de responsabilité de l’application.
Idéalement, les applications sont une partition du plan applicatif : le plan est recouvert par les applications et les interstices entre les applications sont très minces et se résume à des tuyaux stupides (dumb pipes). Autrement, il y a des zones grises de responsabilité et cela peut amener aux syndromes du homme du milieu quand les équipes de projet n’arrivent plus à se parler directement ou encore de la faute à l’intendance quand toute la responsabilité de l’intégration du SI, une tâche colossale et critique, repose sur une équipe centralisée (et parfois petite !).
Emprise sur les environnements
Les environnements sont la résultante des emprises des applications, soit directement, soit au travers des plateformes mutualisées. Le lien entre les éléments d’infrastructure et les application est généralement tracé dans la CMDB. Le cycle de vie des applications et celui des infrastructures sont liés, avec un sens de dépendance des applications vers l’infrastructure. Cette orientation permet d’instruire le dimensionnement des environnements qui peut être statique ou dynamique (élasticité), leur obsolescence ou encore leur fin de vie (décommissionnement). L’emprise peut prendre différentes formes, certaines évidentes, d’autres un peu moins : des pipelines dans l’usine logicielle, des artefacts dans les dépôts, des processus tournant des VM, conteneurs ou fonctions, des données stockées dans les bases ou dans des systèmes de fichiers, mais aussi des messages dans les journaux, des métriques dans la supervision, des tickets dans le système de support, …
Objet d’unité organisationnelle
L’application est-elle sous la responsabilité d’une seule équipe, tout au long de son cycle de vie ? Ou bien existe-t-il une équipe en charge de sa construction et une autre de sa maintenance ? La dissociation entre les phases de construction et de fonctionnement peut répondre à des exigences comptables. Mais elle peut conduire à de forts dérives. Il n’y a pas de garantie que le transfert se passe bien entre les deux équipes. L’application qui passe en mode de maintenance pourrait très bien ne pas être finie : elle peut comporter de la dette avec des blocs de code médiocres, avoir une couverture de test insuffisante impactant son évolutivité, présenter une qualité logicielle médiocre se traduisant par un niveau de service dégradé, ne pas être illustrée par une documentation à jour et précise, conduisant à des dérives par rapport aux intentions initiales de conception ou encore ne pas être doté des outils nécessaires à son exploitation, comme un tableau de bord des indicateurs de fonctionnement, un outil d’administration ou la génération de messages décrivant les événements et les erreurs se produisant dans l’application . Curieusement, avec le passage en équipe produit, l’application peut passer en second plan voire carrément disparaître en tant que concept alors que l’application est bien un des aspects concrets du produit de l’équipe.
Élément d’imputation de budget
Le budget de la DSI est d’une façon ou d’une autre lié à un portefeuille d’applications existantes ou à créer. Les dépenses engagées pour la réalisation, le maintien et le fonctionnement de l’application sont associées à différents postes budgétaires. Aussi, une comptabilité analytique est nécessaire pour expliciter l’application en tant qu’objet d’imputation du budget. On peut se plaindre du coût de l’informatique, mais encore faut-il avoir le moyen de mesurer le coût de possession total des applications !
Outil de création de valeur métier.
L’application doit bien avoir une raison d’être, sans quoi elle aurait déjà dû être décommissionnée ! C’est la contribution de l’application aux processus métier qui devrait être le fondement de son existence (Ce n’est pas toujours le cas. Des jeux politiques sont aussi une autre raison …). Ces processus ont une valeur qui peut faire l’objet d’une quantification par des indicateurs métier (Key Principal Indicator, KPI). Rattacher l’application à ces KPI est la clé pour passer d’un pilotage par les coûts, toujours au désavantage de l’IT (et du métier, au final !) à un pilotage par la valeur. Si on combine le coût de possession et ces KPI, alors on peut faire naître une notion d’efficience économique. Si l’application coûte plus cher mais qu’elle contribue à plus d’activité métier, alors ce n’est pas au final une mauvaise affaire. Également, en rattachant l’application à des processus, on peut répondre à la difficile question de la criticité des applications. L’application n’est au fond critique que si elle contribue de façon incontournable à un processus critique. La criticité des applications fait l’objet de débat passionné car derrière cette question, se pose la hiérarchie des applications et, par voie de conséquence, certains pourraient en déduire une hiérarchie des équipes en charge de ces applications.
Nœud du graphe des flots de données
Le graphe des flots de données a pour nœud les applications et pour lien les flux applicatifs. Dans ce graphe, l’application peut jouer à la fois le rôle de consommateur, de producteur ou de transformateur. Sa capacité technique lui permet de supporter des débits de données plus ou moins importants et de recevoir ou de renvoyer les données avec plus ou moins de célérité. L’application peut (et devrait être) le garant de la qualité des données en renforçant les contrats d’interface sur les flux. La santé des données du SI dépend de celle des applications.
Maison de la donnée
L’application est le lieu de production de la donnée. Quand elle a une exclusivité sur une donnée pendant une phase ou sur la totalité de son cycle, l’application devient un levier d’appropriation de la donnée et sert à la gouvernance de la donnée. Avoir un seul maître pour chaque donnée est un principe facilitant de la cohérence du patrimoine informationnel de l’organisation.
Œuvre d’un savoir-faire technique
L’application est évidemment le produit du savoir-faire d’une équipe mais l’équipe est aussi transformée par l’application. Si la qualité de réalisation de l’application résulte du cadre de coopération mais aussi de la culture technique, l’application est aussi un lieu d’apprentissage à la fois en termes de savoir, de pratique mais aussi de culture. Comme dit le proverbe, c’est en forgeant que l’on devient forgeron. Les équipes, au travers des réalisations et des opérations sur les applications, gagnent généralement en maturité. Ce capital fait de confiance, d’expertise, de pratique, d’engagement est un différenciant fort pour les organisations d’aujourd’hui.
Relations entre applications et organisations
Plusieurs motifs (patterns) reviennent dans la relation entre les organisations et les applications
L’application est un investissement
L’organisation acquiert des applications ou lance des investissements pour les réaliser. Après leur création, les applications passent dans la colonne des charges et il y a une forte incitation à optimiser leur coût de maintenance. Plus l’application est conséquente, plus la décision d’investissement associée pèse lourd et demande du temps d’instruction.
Dans ce contexte, travailler sur les projets peut être plus valorisant que les maintenir. Les prestataires externes attendent d’aller sur les projets quand les internes ont en charge leur maintenance. On observe plusieurs aléas de moralité qui conduisent une accélération rapide de la dette technique. A un certain point, l’application devient obsolète et une décision d’investissement doit être prise pour rétablir dans un état acceptable, la démonter … ou ne rien faire !
Une boite à déposer dans le système d’information.
L’organisation achète ou construit des applications vues comme des boites qui seront ensuite posées dans le SI. Dans ce modèle, le mieux est d’acheter une boite sur étagère car elle existe déjà et a fait ses preuves.
Il reste généralement peu de place pour les boites à façon, car le marché a une offre vaste et un travail profond sur la différenciation de l’organisation doit être mené au préalable pour justifier une réalisation spécifique. Dans ce cadre, le problème revient à trouver la bonne boite et une fois choisie, le projet est considéré comme bien avancé.
Cette approche néglige la « glu » à mettre entre les boites pour assurer la continuité du système d’information, continuité nécessaire pour les processus métier. Cette glu est loin d’être simple à faire , elle demande un peu de talent. Mais c’est elle qui fait que le SI a un bon agencement. Trouver de belles boites ne suffit pas si elles sont mal collées les unes aux autres. La valeur qu’apportera le SI sera réduit et la déception quant à l’effort investi pourra poindre le bout de son nez.
Un autre syndrome est de réduire l’application à la boîte achetée : tout ce qui est nécessaire pour le fonctionnement dans le SI , mais qui n’est pas dans la boite achetée sort de l’application et du périmètre de responsabilité. Mais comme il faut bien que le SI soit fonctionnel, alors ce qui a été exclu se retrouve ailleurs dans le SI et pas forcément là en termes de responsabilité. Cela conduit à des dysfonctionnements organisationnels.
D’abord, le produit
Le produit peut masquer l’application. L’application est le chaînon entre le produit et le composant. Pris entre les deux tendances du marché que sont la démarche produit et la conception en micro-service, l’application peut tout simplement disparaître dans ce processus. Le produit évolue au rythme des sprints et la production des features devient le moteur principal. Pourtant, ce produit doit bien être intégré dans le SI et la situation peut alors se complexifier, car on voit dans certains cas le micro-service qui au départ a une autonomie de déploiement (normal !) finit par avoir son propre cycle de vie. Le niveau des applications s’estompe et le plan applicatif devient une myriade de micro-service, un paysage particulièrement éclaté et complexe à appréhender. L’application fournit pourtant un cadre de compatibilité au travers de son cycle de vie qui permet d’assurer un fonctionnement cohérent de bout en bout.
Démonstrateur technique.
L’application est le lieu de la démonstration du savoir-faire technique de l’équipe, avide de se mesurer aux pratiques les plus innovantes du marché. On tombe dans le syndrome du faire de la technique pour la technique. Quand les équipes IT n’ont pas accès à la vision métier, quand elles sont volatiles et qu’il faut être sur le marché valorisable (bankable ?), alors ce travers peut se comprendre.
Et pour moi, qu’est-ce qu’une application ?
De façon idéale, une application doit être comprise de façon la plus élargie possible dans chacune de ses dimensions. Cela permet d’assurer une couverture sans zone grise et d’obtenir des synergies entre les acteurs de l’organisation.
Concrètement :
- L’application couvre complètement son périmètre de responsabilité;
- L’application est un bon citoyen du SI : elle est intégrée sans couture. Elle expose des endpoints soumis à contrat et consomme les endpoints des autres applications en respectant les contrats;
- L’emprise de l’application et l’ensemble des manifestations est tracée (éventuellement en s’appuyant sur des règles de nommage pratique ou de la labellisation);
- L’application est gérée comme la déclinaison applicative du produit. You build it, you run it !
- L’application a un coût de possession total (ou Total Cost of Ownership, TCO).
- L’application est associée à des processus métier et a des indicateurs métier. Sa trajectoire est pilotée par la valeur et non seulement par le coût.
Ces attendus sont certes ambitieux et pas toujours fréquents. Pour autant, ils indiquent des directions vers où chercher des gains !
Conclusion
Les applications qui étaient auparavant l’objet de démarches pilotées comme la gestion du portefeuille des applications, ont été quelque peu délaissées, alors qu’elles sont souvent le chaînon manquant entre plusieurs acteurs : les développeurs qui les réalisent et le configurent, les ops qui les exploitent dans les environnements, les financiers qui les budgétisent et les métiers qui en font un bon usage. Si nous voulons avoir une organisation fluide du métier jusqu’à l’IT en passant par la DAF, alors il serait dommage de se passer d’un objet qui présente une facette à tous les acteurs de l’organisation.
Vive les applications !
Anonyme
Crédits
