Comment choisir sa solution d'API management

La plupart des sélections d’APIM se jouent sur une grille de fonctions, une série de démonstrations et un prix de licence. Les trois sont insuffisants, et le dernier est mal posé : les fonctions se ressemblent d’un produit à l’autre au-delà d’un socle commun, et la licence n’est pas le poste dominant du coût.

Ce qui départage tient en quatre étapes, dans cet ordre. Chacune élimine des candidats, ce qui évite d’éprouver sérieusement cinq produits.

L’entonnoir donne aussi le calendrier, et il vaut la peine d’être annoncé au départ. Une liste initiale de huit à douze produits se ramène à quatre ou cinq par le cadrage, puis à deux ou trois par les questions d’exploitation, qui se traitent sur dossier.

Seuls ces deux ou trois passent à l’épreuve, parce qu’au-delà l’effort devient réel : quelques jours d’équipe par candidat. Comptez trois à quatre mois entre le cadrage et la décision, dont la moitié en attente de réponses écrites. C’est cette attente, pas le travail technique, qui fixe la date de fin.

Cadrer par les cinq piliers

Avant de regarder un produit, écrire ce que la plateforme doit rendre : découverte, observabilité, gouvernance, médiation, accès. Pour chaque pilier, une phrase sur ce qui est attendu chez vous, pas dans l’absolu.

Ce cadrage sert à deux choses. Il rend la grille lisible par des non-spécialistes, et surtout il fait apparaître les piliers dont personne ne parle. Une sélection qui ne mentionne ni la découverte ni la gouvernance choisira un bon proxy et découvrira dans dix-huit mois qu’elle n’a pas de plateforme.

Une règle pour lire les réponses : un pilier que le produit rend et un pilier qu’il permet de construire ne se valent pas. Six mois de développement pour couvrir une fonction, ce n’est pas une fonction couverte.

Cette règle donne l’échelle de notation, et elle n’a que trois niveaux : 2 le produit le rend en configuration, 1 il le rend au prix d’une intégration que vous savez chiffrer, 0 il permet de le construire. Le zéro pour « permet de construire » n’est pas une sévérité, c’est la traduction de la règle : une fonction à développer est un projet, et un projet ne se compare pas à une case cochée.

Deux précautions rendent la grille honnête. Les poids de chaque pilier s’écrivent avant la première démonstration, sinon ils s’ajustent au produit qu’on préfère déjà. Et les critères éliminatoires de l’étape suivante ne sont pas pondérés : un éliminatoire ne se compense pas par une bonne note ailleurs, sans quoi ce n’est pas un éliminatoire.

Écarter par l’exploitation

C’est l’étape qui élimine le plus, et celle qu’on saute. Huit questions, posées par écrit, avec réponse écrite.

1. La configuration s’exporte-t-elle intégralement dans des fichiers versionnables, et se réimporte-t-elle dans un environnement vide en reproduisant le même état ?
2. Une modification faite hors de ce chemin est-elle détectée ?
3. Quelle est la couverture du provider Terraform, et qu’est-ce qui n’est pilotable qu’en console ?
4. La gateway continue-t-elle à servir si le control plane est arrêté une journée ?
5. Comment se passe une montée de version majeure, et quelle est la fenêtre d’interruption ?
6. Quelles fonctions sont réservées aux paliers supérieurs : portail, authentification unique, traces distribuées ?
7. Que contient exactement le support, et sous quel délai ?
8. En managé, où le trafic est-il traité, et l’auto-hébergé est-il une option de repli contractuelle ? Le sujet est traité dans managée ou auto-hébergée.

Les questions 1, 2 et 4 sont éliminatoires. Une plateforme dont l’état réel ne peut pas être comparé à son état déclaré condamne l’organisation à un écart permanent. Et une gateway qui dépend de son control plane pour servir transforme chaque maintenance en panne. Le détail de ce que ces réponses impliquent est dans le control plane.

Une neuvième question mérite d’être posée sans être éliminatoire : le produit sait-il exposer un contrat OpenAPI existant comme outil pour des agents, et sous quelle gouvernance ? Elle n’élimine pas parce que le sujet bouge vite et se rattrape. Elle renseigne sur autre chose : la vitesse à laquelle l’éditeur suit un standard récent, ce qui est un bon indicateur de ce qu’il fera du prochain. Le fond est traité dans exposer ses API à des agents.

Éprouver sur vos propres API

Une démonstration d’éditeur prouve que l’éditeur sait faire une démonstration. Un essai utile se conduit sur votre matière et par vos équipes, avec un périmètre écrit à l’avance et des critères de succès mesurables.

Le scénario minimal qui discrimine :

• exposer votre API la plus laide, celle avec le contrat approximatif et le comportement bizarre.
• la publier par une chaîne d’intégration, sans toucher la console.
• la promouvoir vers un second environnement, puis revenir en arrière.
• brancher l’authentification sur votre fournisseur d’identité, pas sur celui de la démonstration.
• couper un backend et regarder ce que reçoit le consommateur.
• retrouver un appel précis dans les traces, à partir d’un identifiant de corrélation.

Ces six points prennent quelques jours et révèlent ce qu’aucune grille ne montre. Le sujet est développé dans le POC d’éditeur est une démo.

Chiffrer sur trois ans

Pas le prix unitaire : le total à trois ans, sur un scénario écrit par vous et soumis tel quel à chaque candidat. Les unités de facturation ne sont pas comparables entre elles, et les écarts entre les réponses en apprennent plus que n’importe quel comparatif public.

Le scénario tient sur une page et se soumet à l’identique. Il porte le volume d’appels mensuel d’aujourd’hui et celui projeté à trois ans, la taille moyenne des réponses, le nombre d’environnements et de régions, le nombre d’API et de consommateurs, la durée de conservation des journaux imposée par votre conformité.

Exigez ensuite que chaque devis porte les mêmes lignes, y compris celles que le candidat juge nulles chez lui : licence, environnements hors production, sortie de données, rétention des journaux, portail, authentification unique, traces, support, revalorisation annuelle. Un zéro assumé est une information. Une ligne absente est une surprise à venir.

Les variables à fixer, les lignes absentes des devis et le coût de sortie sont détaillés dans combien coûte vraiment une plateforme.

Ce qui ne doit pas décider

Quatre arguments reviennent en comité et aucun ne porte d’information sur votre contrainte. La longueur de la grille de fonctions, qui sert à différencier les plaquettes au-delà d’un socle commun. Le quadrant d’un analyste, qui classe des éditeurs sur un marché mondial.

L’avis de l’intégrateur, souvent partenaire d’un éditeur, ce qui est légitime et doit être su : demandez quels produits il est certifié à revendre. Le nom, enfin, parce que le meilleur produit du marché mal exploité vaut moins qu’un produit moyen tenu par une équipe qui sait ce qu’elle fait.

Reste une question à poser quand la préférence est faite, et une seule : combien de policies devront être écrites dans le langage propre à l’éditeur ? La réponse chiffre la migration suivante. Personne ne la provisionne, et c’est pourtant le seul nombre de tout le dossier qui engage l’organisation au-delà du contrat.