Note de l’auteur: Le sujet abordé étant plutôt complexe, j’ai scindé mon propos en deux posts, l’un consacré à l’aspect technique, l’autre à l’aspect stratégique et commercial. Le post qui suit se penche sur la dimension stratégique du problème. Pour un traitement technique de cette approche, vous pouvez lire ce post.

Les dangers de la « mentalité de silo » dans le monde des API

Bjarne Stroustrup, l’inventeur du C++, déclara un jour :

« Avec le C, il est facile de se tirer une balle dans le pied; le C++ rend ça plus difficile, mais quand vous le faites, ça vous flingue toute la jambe. »

J’aime beaucoup cette citation. J’en ai personnellement connu la justesse en codant en C++. Mais elle illustre un problème plus vaste, et récurrent, en architecture logicielle. Beaucoup d’efforts d’innovation, bien intentionnés, ont permis de réduire le risque de problèmes mineurs ou moyens au sein d’un logiciel, tout en créant des risques de nouveaux problèmes plus ponctuels mais catastrophiques.

D’autres efforts, ni inventifs ni bien intentionnés, empirent cette situation. J’évoque l’enfermement propriétaire, la tendance qu’ont certaines plateformes logicielles à faire des choix à la place de leurs utilisateurs, développeurs ou intégrateurs. Cette tendance peut être délibérée ou inconsciente : les développeurs agissent en fonction des cadres conceptuels qui leurs sont familiers, et ont parfois du mal à envisager des solutions différant de leur logique. En management, cette difficulté d’une équipe à s’extraire de ses propres cadres de pensée s’appelle « mentalité de silo ».

Innovations incrémentales ou radicales ?

L’évolution du C vers le C++ était volontairement incrémentale, pour profiter des développeurs déjà familiers avec la syntaxe du C. C’est une tactique qui se défend. Mais quand le Java est arrivé, il ne fit qu’une bouchée du C++, en termes d’adoption et de popularité. Ce succès ne résulta pas d’une meilleure syntaxe ou d’une supériorité intrinsèque, mais simplement parce que le Java ne traînait pas le boulet du passé, et qu’il était conçu pour la programmation orientée-objet dès le début.

La « mentalité de silo » peut être inconsciente ou délibérée — en mon expérience, le cas inconscient est plus fréquent. Mais quelle qu’en soit la cause, ses effets néfastes sur l’innovation et sur l’intégration sont puissants. La combinaison de l’incrémentalisme et de cet effet de silo a des conséquences catastrophiques pour l’utilisabilité d’un logiciel, pour sa durée de vie et pour sa rentabilité.

Les APIs RESTful peuvent être un moyen efficace de se protéger des « silos logiciels ». Elles obligent à produire un accès ouvert et documenté aux ressources et fonctionnalités de n’importe quel système doté d’une telle API. Mais l’ajout d’une API ne rend pas miraculeusement un système ouvert, et ne garantit pas une co-existence harmonieuse avec d’autres systèmes. L’état d’esprit de l’architecte du logiciel persiste.

Quand vous utilisez n’importe quel logiciel, vous adhérez à la perspective de son architecte et de ses développeurs.

Une API ne change pas cette vérité fondamentale. La mentalité de silo y est particulièrement insidieuse, car les API semblent promettre (parfois à tort) ouverture et liberté.

Fournir un grand nombre de endpoints ne résout pas tous les problèmes (et peut être contre-productif). L’emploi de Swagger / OpenAPISpec, utile certes, n’est pas suffisant non plus. Pour construire des API véritablement ouvertes, il nous faut changer notre façon de penser.

Qu’est ce que l’incrémentalisme vient faire là-dedans ?

N’importe quel vendeur de logiciel vous le dira: la fragmentation des versions est un vrai cauchemar. Imaginez ce que les développeurs et commerciaux d’Android pensent de ce graphique:

Aïe! Et Nougat (Android 7.0) n’y figure même pas !

Ce type de longue traîne dans la distribution offre un constat assez terrible de la difficulté à faire adopter la dernière (et, on l’espère, la meilleure) plateforme. 81.3% de la base d’Android n’est pas sur Marshmallow.

Si vous développez des applis Android, pour couvrir le pari, il suffit de cibler les versions « 4.2.x ou plus récentes » — ce qui donne 89.1% de la base Android comme public potentiel, à condition de limiter les fonctionnalités de votre app au dénominateur commun entre ces versions. Mais pour l’équipe Android, ces nombres révèlent une vérité pénible. Tout ce qui date d’avant Marshmallow représente un boulet qui freine leur capacité d’innovation.

Comme pour la mentalité silo, ce problème s’aggrave dans le domaine des API. La nouvelle version d’une API doit offrir une rétro-compatibilité complète, un système de négociation de versions, ou les deux en même temps. En leur absence, la nouvelle API « casse » toute application qui s’en servait. En revanche, un développeur d’applications Android qui ne cible que Marshmallow réduit son marché potentiel, mais ne casse rien. Les développeurs d’API n’ont pas le luxe de faire ce choix.

Toute application exploitant une API devient partie intégrante du « système de lègue » de cette API.

Cette réalité pousse les architectes d’API à l’incrémentalisme, précisément parce que le coût du versioning est beaucoup plus élevé que pour les développeurs d’applications.

Pourtant, les API exigent avant tout une évolution rapide et de l’adaptabilité. Une situation paradoxale.

Que faire ?

Récapitulons les problèmes-clé :

  1. La mentalité de silo, volontaire ou non, empêche la supposée « industrie logicielle » de devenir une industrie au plein sens du terme: un écosystème dans lequel l’innovation et la compatibilité ne s’excluent pas mutuellement.
  2. Tout logiciel reflète un état d’esprit et une perspective propres à ses créateurs – ce qui n’est pas toujours évident, mais souvent limitant.
  3. L’incrémentalisme est une conséquence regrettable et dangereuse de la façon dont nous développons les logiciels aujourd’hui.
  4. La mentalité de silo et l’incrémentalisme sont particulièrement toxiques pour les APIs.
  5. La nature des API pousse leurs créateurs vers l’incrémentalisme.

Le mot anglais « quixotic » nous vient de Don Quichotte, de Cervantes, le premier roman moderne (belle innovation disruptive!). Le dictionnaire Merriam-Webster nous en donne cette définition : « Un manque de sens pratique, particulièrement dans les ambitions idéalistes; particulièrement, caractérisé par un romantisme impétueux, ou une action chevaleresque démesurée. » Définition dérivée de la prédilection du protagoniste au combat singulier contre les moulins.

Au risque d’être moqué pour la futilité chimérique de notre engagement, nous sommes décidés de partir en guerre contre les silos. Nous proposons pour cela d’adopter pour nos API les principes suivants :

  1. Aucun intérêt propriétaire. Nous ne faisons que des API, de sorte que nous n’avons aucune plateforme à défendre. Nos API doivent avoir un mérite intrinsèque afin d’intéresser le marché.
  2. 100% Logiciels Libres. Tous nos produits seront open source, de sorte que si, accidentellement, nous cédons à la mentalité de silo, nous pourrons compter sur d’autres regards pour nous le signaler et/ou pour le corriger.
  3. Nouvelle version = nouvelle API. Comme pour des pièces interchangeables dans l’industrie, si nous changeons les spécifications d’une API, nous la traitons comme un nouveau produit, pas comme la v2.1.3 du « Produit X », qui ne ressemble plus du tout à la v1.0.
  4. LTS pour les API. Le Long-Term Support est utilisé pour de nombreux systèmes, et doit être pour nos API RESTful un impératif catégorique. Concevoir une API en fonction du LTS donne aux consommateurs une fenêtre de temps fiable, qui leur permet de gérer le cycle de vie du projet impliquant cette API.
  5. Agnosticisme proactif. Nous nous engageons à éviter de prendre des décisions qui reviennent à l’utilisateur de l’API: par exemple, quelle technologie de stockage de données (MySQL vs. Oracle vs. Elastic), ou quel format de transfert (JSON vs. XML). Il ne s’agit pas d’abdiquer notre bon jugement, seulement de ne pas imposer les choix qui en découleraient aux développeurs.

Dans la deuxième partie de ce post, je décrirai un système de contrôle d’accès qui s’accorde avec ces principes.

Nous attendons vos réactions et critiques. Ces posts n’ont pas pour but de prouver que nous avons raison, mais plutôt de démarrer une conversation avec nos lecteurs, pour que nous puissions comprendre et découvrir la vérité ensemble.

Share This