Les questions absentes de votre appel d'offres
Les grilles d'appel d'offres APIM font cent lignes sur les fonctionnalités et trois sur l'exploitation. Les dix questions qui manquent, et ce que leurs réponses révèlent.
Les appels d'offres APIM se ressemblent tous : une grille de cent à trois cents lignes, héritée d'un cabinet ou d'un projet précédent, où chaque éditeur répond « conforme » à 90 %. La grille est longue parce qu'elle est facile à allonger : chaque fonctionnalité est une ligne. Et elle ne discrimine pas, parce que les produits du marché couvrent tous l'essentiel fonctionnel depuis des années.
Ce qui les distingue est ailleurs, dans des questions qui tiennent en dix lignes et qui manquent dans presque toutes les grilles.
Les dix questions
1. Décrivez la montée de version de votre produit, de N-1 à N, sur une plateforme en production. Durée, coupure ou non, retour arrière possible ou non. C'est l'opération qui fera le plus souffrir vos équipes pendant dix ans, et elle n'est jamais dans la grille.
2. Votre configuration complète est-elle exportable et applicable par API, sans aucune action console ? Pas « avez-vous une API d'administration » : la question est la couverture. Chaque objet configurable à la console doit l'être par la chaîne, sinon l'écart deviendra votre stock de configuration ingérable.
3. Que voit l'exploitant pendant une panne d'un de vos composants internes ? La qualité des diagnostics internes du produit, messages d'erreur compris, décide de la durée de vos incidents. Demandez une démonstration sur panne provoquée, pas une capture de dashboard.
4. Quel est le comportement des gateways quand le control plane est indisponible ? La bonne réponse tient en un mot : rien. Le trafic continue, la configuration est figée. Toute autre réponse mérite un examen approfondi.
5. Donnez la liste exhaustive des métriques et journaux exportables vers notre outillage. Votre observabilité doit vivre dans vos outils, pas dans la console de l'éditeur. Le format, le délai et le coût de l'export sont trois pièges classiques, le troisième surtout : certains modèles tarifaires facturent la sortie des données.
6. Sur quel élément votre tarification évolue-t-elle, et que se passe-t-il au double de notre trafic prévisionnel ? Par appel, par gateway, par cœur, par environnement : chaque modèle a un scénario où la facture explose. Le calcul au double du prévisionnel révèle le vôtre avant la signature.
7. Quelles fonctionnalités de votre réponse sont en disponibilité générale, et lesquelles sont en feuille de route ? Avec dates et engagement contractuel. La frontière entre le produit et la roadmap est la zone la plus créative des réponses d'appel d'offres.
8. Combien de profils opérationnels sur votre produit existent sur notre marché de l'emploi ? Un produit brillant sans vivier de compétences locales vous lie au professional services de l'éditeur pour chaque évolution. Le coût de ce lien n'est dans aucune grille, et c'est exactement ce qu'on mesure en cherchant, pour un client, qui sait vraiment tenir la plateforme qu'il achète.
9. Donnez trois références clients à notre échelle, dont une que nous choisirons d'appeler sans votre présence. L'entretien de référence sans l'éditeur dans la pièce vaut toutes les démonstrations. Les questions à poser tiennent en trois lignes : montée de version, pire incident, ce qu'ils referaient autrement.
10. Que devient notre configuration si nous partons ? Format d'export, documentation du format, clause de réversibilité. La réponse mesure la confiance de l'éditeur dans son produit : ceux qui retiennent leurs clients par la difficulté de sortie le savent.
Comment lire les réponses
Une question ouverte n'a d'intérêt que si on a écrit d'avance ce qui disqualifie. Sinon la réponse est longue, aimable, et notée « conforme » comme le reste.
| Question | La réponse qui élimine |
|---|---|
| 1. Montée de version | Une coupure annoncée sans durée, ou un retour arrière « au cas par cas » |
| 2. Configuration par API | « Tout est possible par API », sans liste des objets qui n'y sont pas |
| 3. Panne interne | Une capture de tableau de bord au lieu d'une panne provoquée |
| 4. Control plane indisponible | Tout ce qui n'est pas « le trafic continue, la configuration est figée » |
| 5. Export des journaux | Un format propriétaire, ou une facturation à la sortie non chiffrée |
| 6. Au double du trafic | Un refus de chiffrer le scénario que vous avez écrit |
| 7. Produit et feuille de route | Une date sans engagement contractuel |
| 8. Vivier de compétences | Un renvoi vers les équipes de l'éditeur |
| 9. Références à appeler seul | Une seule référence, ou toutes hors de votre échelle |
| 10. Réversibilité | Un export dont le format n'est pas documenté publiquement |
Deux règles de forme comptent autant que les questions. Ces dix lignes forment un lot séparé, avec son propre poids, sinon elles se noient dans les trois cents conformités de la grille fonctionnelle. Et chaque réponse porte le nom et la fonction de qui l'a écrite : une réponse signée par un ingénieur d'avant-vente n'a pas le même statut qu'une réponse signée par le support.
Le reste est affaire de vérification. Faites éprouver les réponses des deux finalistes par l'épreuve : une réponse d'appel d'offres est une promesse, une épreuve est un fait. La décision mérite d'être écrite à partir de faits, ne serait-ce que pour la défendre dans trois ans, quand quelqu'un demandera pourquoi on a choisi celle-là.
Publié en mars 2026.
Sur le même sujet