Critères d'acceptation d'un runtime d'intégration : grille type cahier des charges

La plupart des cahiers des charges d'intégration se lisent comme une liste de fonctionnalités. Connecteurs¹⁰, mapping, « temps réel », parfois un mot sur la sécurité. Puis la signature tombe, et six mois plus tard personne ne sait dire ce que devient un message en échec à 3 h du matin, ni ce que coûterait de quitter la plateforme. Ce n'est pas un détail d'exploitation. C'est le sujet.

Un runtime d'intégration¹, c'est l'environnement qui exécute vos flux : moteur, files d'attente, supervision. Qu'il soit emballé en iPaaS² SaaS, en ESB³ on-premise, en stack Python maison ou en plateforme émergente, les enjeux de comité sont les mêmes : continuité opérationnelle, propriété de la logique, trajectoire de coût sur cinq ans. Cette grille est une checklist d'acceptation, utilisable en appel d'offres, en revue architecture, ou avant de construire soi-même.

Précision utile avant d'aller plus loin : Portlane est encore en développement actif, sans date de sortie publique. Ce qui suit décrit une grille de décision et un positionnement produit, pas une migration que vous pourriez lancer cette semaine. BastionLab reste le bras conseil ; Portlane porte le produit. Deux rôles, volontairement séparés.

Les signaux qu'on entend en comité

Le déclencheur est rarement une panne spectaculaire. C'est une accumulation que DSI, COO et DAF finissent par nommer à voix haute :

• La démo a tout coché ; la question « qui rejoue un message en prod ? » est restée sans réponse claire.
• La facture est passée au budget récurrent, mais le coût de sortie⁸ n'a jamais été chiffré.
• Une seule personne sait vraiment faire évoluer les flux ; le recrutement bloque sur une compétence de niche.
• Les échecs partiels disparaissent ou s'accumulent sans DLQ⁴ lisible ; l'astreinte improvise.
• Le métier demande un SLA¹³ de reprise ; ops répond « on regarde les logs ».
• Personne ne peut dire si la logique vit dans votre git ou uniquement dans la console éditeur.

Aucun de ces points n'est une attaque contre un produit. Ce sont les symptômes d'un choix fait sans critères d'acceptation d'exploitation. Cochez exigeant. Un éditeur qui esquive une ligne sur le rejeu⁵ ou l'export vous coûtera plus cher que la ligne de licence.

1. Modèle d'exécution

Si le message disparaît entre deux étapes, vous n'avez pas un runtime, vous avez un pari.

• Chemin de données explicite (entrée → transformation → sortie) documenté.
• Messages persistés entre étapes, pas seulement en mémoire process.
• Retry automatique configurable avec plafond et backoff.
• DLQ⁴ ou équivalent pour les échecs non transitoires.
• Rejeu⁵ depuis la supervision avec trace (qui, quand, quel message). Voir playbook rejeu.
• Exécution self-hosted⁶ ou cloud au choix, contrainte de souveraineté¹⁵ écrite.

2. Propriété et portabilité

C'est la ligne que le DAF et le gérant doivent relire deux fois. Louer l'exécution est une option ; louer la logique métier en est une autre.

• Logique métier en format ouvert (code source, pas binaire propriétaire seul).
• Versionnement dans votre git, pas uniquement dans la console éditeur.
• Tests automatisés possibles hors plateforme (CI).
• Export ou réécriture documentée. Coût de sortie⁸ chiffré ou chiffrable.
• Pas de dépendance à une seule personne « expert studio ».
• Licence : licence à vie ou abonnement. Trajectoire sur cinq ans écrite noir sur blanc.

3. Observabilité et exploitation

Un COO ne demande pas un dashboard joli. Il demande qui porte le runbook quand le flux critique casse.

• Santé des workers / moteurs visible sans SSH.
• Journal des exécutions consultable (succès, échec, durée).
• Corrélation message ↔ erreur ↔ étape.
• Alertes sur échecs répétés et profondeur de DLQ⁴.
• Runbook type pour le rejeu⁵, avec propriétaire nommé.
• Rôles : qui peut rejouer en production, et sous quel contrôle.

4. Périmètre fonctionnel (honnêteté)

Payer une suite complète pour dix flux de sync est un classique. Exigez le périmètre déclaré, pas le catalogue marketing.

• Sync données batch et/ou temps réel. Périmètre déclaré.
• BPM¹¹, MDM¹², gouvernance API⁹ : inclus ou explicitement hors scope.
• Connecteurs¹⁰ : vos systèmes couverts par API⁹ native vs connecteur payant.
• Transformations complexes : limites documentées (volume, mémoire, timeout).
• Pas de promesse « tout ESB³ » si vous n'avez besoin que de dix flux.

5. Sécurité et conformité

• Secrets hors code (vault, variables chiffrées).
• Chiffrement en transit et au repos. Où sont les données en échec ?
• Journal d'audit des actions admin (rejeu⁵, déploiement).
• RGPD : localisation des métadonnées et rétention des logs.
• Mises à jour sécurité : qui publie, à quel rythme (surtout forks¹⁴ type Talaxie).

6. Migration et coexistence

• Bascule flux par flux sans big bang obligatoire.
• Parallèle ancien / nouveau chemin supporté.
• Inventaire des flux facilité. Voir checklist inventaire.
• Rollback documenté après bascule.

Scoring rapide en comité

Pour chaque candidat, classez chaque ligne en trois cases : Bloquant (sans ça, on ne signe pas), Acceptable sous dette (ok six mois, plan écrit), Hors scope (volontairement exclu). Un iPaaS² qui coche tout sauf la propriété du code est un loueur : ce n'est pas une erreur si le comité l'assume. Un produit qui coche la propriété mais n'est pas encore prêt pour la prod est un pari. Portlane est dans cette seconde case aujourd'hui.

Comment Portlane se positionne (honnête)

• Must visés : Python versionné, files fiables, rejeu⁵, supervision, licence à vie, self-hosted⁶.
• Hors scope assumé : BPM¹¹, MDM¹², catalogue de connecteurs¹⁰ massif, designer visuel.
• État actuel : développement actif ; validez par pilote, pas par PowerPoint.
• Deux rôles : BastionLab conseille et intègre ; Portlane est le produit. Ne les confondez pas dans le cahier des charges.

Si votre débat porte plutôt sur le modèle commercial (louer vs posséder), voir iPaaS vs runtime et posséder vs louer l'intégration. Pour le coût de sortie d'un iPaaS déjà en place : coût de sortie iPaaS.

Pour aller plus loin

• Ops : rejouer un flux en échec
• DLQ : dead letter queue
• Inventaire : cartographier les flux
• Sortie iPaaS : migrer hors Workato / Boomi
• Produit : pourquoi nous construisons Portlane

Questions fréquentes

Ces critères servent à acheter ou à construire ?

Aux deux. Un cahier des charges iPaaS², un ESB³, ou un choix « Python + orchestration maison » doit répondre aux mêmes questions d'exploitation : persistance, rejeu⁵, observabilité, propriété, coût de sortie⁸. La grille ne privilégie pas un camp ; elle empêche de signer (ou de coder) en oubliant l'astreinte.

Faut-il exiger un designer visuel dans le cahier des charges ?

Seulement si vos équipes en ont réellement besoin et que vous acceptez le lock-in⁷ de configuration. Pour de la sync données critique (commandes, stock, facturation), nous privilégions du code versionné. C'est le pari Portlane. Exiger un studio « parce que tout le monde en a un » est souvent un mauvais calcul.

Le catalogue de connecteurs est-il un critère bloquant ?

Non si vos systèmes exposent des API⁹ documentées. Le catalogue accélère le démarrage et ralentit la sortie. Listez vos systèmes réels avant de payer pour quatre cents connecteurs¹⁰ dont vous en utiliserez douze. Voir pourquoi pas de catalogue de connecteurs.

Comment un DAF doit-il lire cette grille ?

Trois lignes comptent pour le budget : licence (abonnement vs licence à vie), coût de sortie⁸ chiffré, et dépendance à une compétence de niche. Un produit moins cher à l'année 1 qui enferme la logique dans un format illisible est souvent plus cher à l'année 5.

Portlane coche-t-il déjà tous les Must ?

Non. Développement actif, sans date de sortie publique. Les Must visés (Python versionné, files fiables, rejeu⁵, supervision, licence à vie, self-hosted⁶) sont le cadrage produit. Utilisez la grille pour un pilote honnête, pas pour valider une migration complète ce trimestre. BastionLab (conseil) et Portlane (produit) sont deux rôles distincts.

Qui valide ces critères en interne ?

IT ops + intégration au minimum ; métier sur les SLA¹³ de rejeu⁵ et les fenêtres de maintenance. Achats seuls produisent des contrats jolis et des astreintes mauvaises. Un gérant peut trancher le modèle (louer vs posséder) ; la DSI doit pouvoir dire qui rejoue un message à 3 h du matin.

Glossaire

• ¹ Runtime d'intégration : environnement qui exécute les flux (moteur, files, supervision).
• ² iPaaS : plateforme d'intégration cloud, en général sous abonnement.
• ³ ESB : bus de services d'entreprise.
• ⁴ DLQ (dead letter queue) : file des messages en échec définitif.
• ⁵ Rejeu (replay) : retraitement contrôlé d'un message après échec.
• ⁶ Self-hosted : exécution sur votre infrastructure.
• ⁷ Lock-in : dépendance fournisseur qui rend la sortie coûteuse.
• ⁸ Coût de sortie : effort et budget pour quitter la plateforme.
• ⁹ API : interface standardisée entre logiciels.
• ¹⁰ Connecteur : module éditeur pour brancher une application.
• ¹¹ BPM : orchestration de processus métier.
• ¹² MDM : référentiel de données maître.
• ¹³ SLA : engagement de niveau de service.
• ¹⁴ Fork : copie maintenue d'un logiciel open source.
• ¹⁵ Souveraineté : contrôle de l'hébergement et des données.