aPaaS et autonomie

À chaque occasion qu’il m’a été donné de travailler pour une organisation, peu importe sa taille, j’ai croisé un service d’application qui avait été implémenté avec une plateforme de développement rapide d’applications (RAD).

Dans les situations les plus rudimentaires, il s’agissait de feuilles de calculs sous stéroïdes (Microsoft Excel). Dans d’autres contextes, j’étais plutôt amené à maintenir des bases de données Microsoft Access, avec des formulaires, des états, et du code VBA.

Certes, j’en conviens, par moment, l’implémentation avec ces outils flirtait plus avec du codage d’application que du RAD.

Dans chaque situation rencontrée, ces plateformes RAD étaient officiellement distribuées aux utilisateur·rice·s sur leur poste. Et pour chaque situation, ces services d’application comblaient un manque.

Microsoft Excel ou Access n’ont pas disparus. Depuis quelques années, toutefois, des plateformes aPaaS (application Platform as a Service) ont vu le jour et simplifient encore plus l’implémentation de services d’application. Car, oui, les utilisateur·rice·s ont toujours des besoins qui ne sont pas couverts par les services d’application officiellement soutenus par l’organisation.

Mais alors, comment peut-on faire différemment, voire mieux aujourd’hui ?

Pour mieux comprendre, commençons depuis la genèse du service d’application en nous mettant à la place de ses concepteur·rice·s.

Aux prémices de l’existence d’un service d’application, ses concepteur·rice·s portent un regard sur le paysage, le contexte, dans lequel le service sera construit, et cela d’un point de vue :

Métier : qui il servira, quelle capacité le soutient, quels processus sont implémentés.
Donnée : quelles données seront traitées, organisées, sécurisées, distribuées.
Application : quelles applications interagissent avec les données et implémentent les processus métier.
Technologie : quelles technologies matérielles et logicielles soutiendront l’entièreté de cette construction.

Sur chacun de ces points, des choix devront donc être faits. Et on souhaite que ces choix soient faits par des décisions collégiales.

Technologie

Au moment de commencer à construire le service d’application, il faudra donc prendre position sur les technologies à utiliser. Pour faciliter de telles prises de position, l’organisation dispose certainement de standards, directives, et principes. L’un de ces principes peut être « Souscrire plutôt que construire ». En effet, on choisira de prendre un service du marché (SaaS) avant de se lancer dans un chantier. Si toutefois, il s’agit d’un service émergeant, propre à l’organisation et qui la différencie, alors on choisira de le bâtir ab nihilo.

Mais est-ce vraiment ab nihilo ?

Lorsque l’on commence à parler de développement informatique, il est coutumier de négliger les technologies qui permettent de générer rapidement un service d’application. On a tendance à débattre pour savoir si telle ou telle technologie, tel ou tel language de programmation, etc. sont la meilleure manière de construire un service d’application. Faut-il donc coder le service d’application ou le bâtir avec une plateforme qui me donne les briques de base sans que j’aie à coder moi-même ?

C’est pourquoi, la plupart des articles traitant des plateformes aPaaS expliquent les bénéfices qu’elles apportent :

Distribution du développement vers tous les employés,
Scalabilité du service,
Agilité de l’organisation et du domaine métier,
Réduction du temps de mise sur le marché du service,
Intégration facilitée avec d’autres services d’application,
Allègement des contrôles qualité,
Accroissement de la sécurité des données,
etc.

Ces avantages sont probablement indéniables et évidents. Et peuvent même être la raison pour l’adoption de ces plateformes. Je ne participerai pas à une guerre de tranchées qui débat de la véracité de chacun de ces éléments.

Dans le monde des métriques, de la distinction entre le qualitatif et le quantitatif, ces plateformes apportent quelque chose qu’elles n’avaient pas prévu : chahuter les organisations.

Autonomiser les collaborateur·rice·s…

Wikipedia a permis de réduire la hiérarchie et de donner à chaque personne la possibilité de contribuer à la rédaction d’une encyclopédie sans que cette personne ait été au préalable intronisée en tant qu’éditrice.

Une plateforme aPaaS (Low-Code ou No-Code) offre à chaque personne de l’organisation la possibilité de contribuer, de définir et de faire évoluer le système d’information de l’organisation. Cette personne devient un·e développeur·euse citoyen·ne et fait dès lors partie de la communauté des développeur·euse·s.

Il est vrai que les architectes d’entreprise souhaitent souvent avoir le contrôle sur le panorama du système d’information. Des postulats de ce type sont généralement articulés :

Les processus métier doivent être tous alignés dans les unités de l’entreprise,
Chaque service d’application doit avoir un retour sur investissement positif,
Il faut n’avoir qu’un service d’application pour une capacité métier,
Il faut réduire le nombre de technologies déployées,
etc.

Ces injonctions, qui conduisent généralement à la constitution de comités de validation, de contrôles, de définition d’architectures standards, alourdissent l’organisation et ne donnent que l’illusion de maîtrise en imposant une bureaucratie bien prégnante, elle.

Avec les plateformes aPaaS, même si une gouvernance minimale est nécessaire, les architectes d’entreprise, doivent néanmoins relâcher leur emprise sur le système d’information. Après tout, ce dernier ne leur appartient pas.

Dans le cadre des plateformes aPaaS, avec les services que les développeur·euse·s citoyen·ne·s qu’ils fournissent, ces dernier·ère·s contribuent ensemble à la conception et l’élaboration, et au maintien du système d’information.

En fait, plus que le système d’information qu’ils conçoivent, créent, ou maintiennent, les développeurs citoyens redéfinissent au fil de leur activité métier et de l’exécution de leur processus, la forme et l’étendue de leur organisation.

… Ou figer l’organisation

Comme l’énonçait Melvin Conway, le système conçu par une organisation produit un design qui est une copie de la structure de communication de leur organisation.

Les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation.

Melvin E. Conway

Avec cette affirmation, posée sous forme d’adage, on peut également s’imaginer qu’il y a un risque que le système d’information conduise à une cristallisation plus forte de l’organisation. Peu importe, d’ailleurs, les technologies utilisées pour créer ce système d’information.

On peut très bien imaginer une entreprise avec une forte composante hiérarchique ; les employés ont des tâches très spécialisées et ne comprennent pas l’entièreté de ce que fait l’organisation. Tant et si bien qu’il se peut que certaines tâches sont faites à double ou très souvent, pour rien. Prenons un exemple pour illustrer ce propos.

Une histoire de papier

Chaque mois, les spécialistes impriment les résultats de tests pour les transmettre à une autre unité du laboratoire. Ces spécialistes ne connaissent pas grand-chose de cette autre unité. L’interface, convenue longtemps avant que ces spécialistes ne travaillent ici, est de fournir les résultats sous forme papier : une feuille par résultat.

L’unité réceptrice a d’ailleurs toujours refusé que ce processus soit numérisé. Pour les spécialistes cela est incompréhensible, mais cette tâche n’est pas trop pénible. N’empêche que d’un clic tous les détails pourraient être fournis dans une feuille de calcul.

Un jour, néanmoins, le département logistique décide de changer de type de papier pour des raisons économiques ; le nouveau papier est moins épais. Le changement prit du temps, car les stocks de papier sont renouvelés tous les 6 mois.

Quelques mois plus tard, le département recevant les feuilles de résultats panique et tire alors aussitôt la sonnette d’alarme. Leur processus ne fonctionne plus !

Il est difficile de voir au premier abord pourquoi la réduction de l’épaisseur du papier est un problème. Et pourtant, il aurait fallu que le spécialiste puisse discuter avec ses autres collègues pour mieux comprendre comment étaient traités les résultats.

En effet, seul le nombre de tests étaient important. Et c’est par la mesure du poids du tas de feuilles que leur nombre étaient calculé. Le papier étant moins épais, il était aussi moins lourd. Au final, le calcul du nombre de tests était simplement erroné. Ici, le principe « Contractualiser » aurait permis de prévenir cet écueil.

Une plateforme aPaaS ne résout évidemment pas cette situation - ici des difficultés de communication - directement. Elle peut même la figer et rendre automatique des tâches absurdes et inutiles.

Par contre, le coût faible des services d’application et de la plateforme aPaaS sur lesquelles ceux-là sont implémentés permet d’en ajouter ou d’en supprimer sans avoir de complexe.

Dans notre exemple, au lieu d’imprimer les feuilles de résultats, les spécialistes peuvent facilement changer l’interface de leur service pour qu’il renvoie, par une API ou même par courriel pour une interface plus rudimentaire, le nombre de résultats à l’autre unité.

Cette exemple semble extrême, mais le livre « Les Décisions absurdes » de Christian Morel recense des situations bien plus ubuesques.

Conclusion

Qu’est-ce qui est différent d’alors ?

Les services d’applications de ces développeur·euse·s ne sont plus éparpillés sur des postes clients. Ils sont rendus visibles sur une plateforme. Les données sont sauvegardées et sécurisées. Les problèmes de performances sont gérés.

Néanmoins, si un fournisseur de plateforme aPaaS vous fait miroiter tous les avantages que nous avons vus dans le chapitre « Technologie » sans vous expliquer le bouleversement, plus ou moins grand, qu’apporte une telle plateforme au sein de l’organisation, alors vous avez affaire à un charlatan. Vous savez, le genre de personnes parcourant autrefois les places publiques pour vous vendre un médicament miracle avec une grande éloquence et beaucoup de confiance. Aujourd’hui, il s’agirait plutôt d’influenceur·euse·s sur Instagram ou Tik Tok essayant de vous vendre le Web3 ou des cryptomonnaies.

Les plateformes aPaaS sont le présent au même titre que d’autres briques de base, composants, qui constituent aujourd’hui déjà nos systèmes d’information. On verrait mal en effet, de programmer tous les logiciels en assembleur ou en code machine aujourd’hui.

Il convient donc d’adopter les plateformes aPaaS comme une brique de base, mais aussi :

de l’utiliser comme un élément libérateur de l’organisation,
d’aider à faire émerger la gouvernance nécessaire à la plateforme,
de constituer une communauté de développeur·euse·s citoyen·ne·s qui échangent sur leur problématique métier, non seulement ensemble, mais aussi avec les développeur·euse·s d’application codées, des architectes, des concepteur·rice·s UI/UX, etc.,
d’inclure les consommateur·rice·s des services ainsi fournis dans un processus continuel.

Finalement, la question n’est pas « faut-il une plateforme aPaaS ou non ? », mais plutôt « comment adopter une plateforme aPaaS ? »