La plateforme doit enlever du travail, pas ajouter une équipe d’attente

Dans ce scénario illustratif, sans attribution à un client de CYTIZEN, Julien pilote la modernisation des applications autour d’un ERP. Une équipe propose une plateforme cloud commune pour livrer plus vite. Les métiers entendent « autonomie » ; les développeurs découvrent un portail supplémentaire et des demandes qui doivent toujours passer par plusieurs équipes. La plateforme possède un catalogue, mais le parcours permettant d’obtenir un environnement sûr et utilisable reste largement manuel.

Le platform engineering consiste ici à traiter la capacité interne comme un service destiné à ses utilisateurs. Il ne suffit pas d’assembler des outils ni de remplacer les tickets par un formulaire. La première question est : quelle opération fréquente et coûteuse sera réellement simplifiée ? Julien retient le parcours de création d’une extension applicative intégrée à SAP, de son environnement de développement à sa mise en production. Le périmètre ne comprend pas le remplacement du cœur ERP.

Décrire un parcours standard et ses exceptions

L’équipe choisit un parcours supporté : dépôt de code, identité de service, environnement, accès autorisé aux interfaces ERP, secrets, journalisation, déploiement et supervision. Chaque étape possède une sortie vérifiable et un propriétaire. Un nouvel environnement n’est pas considéré comme livré si l’application ne peut pas atteindre les interfaces nécessaires ou si ses journaux ne sont pas consultables par le support. Le portail doit donc rendre la progression et les blocages visibles, et pas seulement générer un numéro de demande.

Les exceptions sont explicites : connexion à un site industriel isolé, données sensibles, contraintes de disponibilité, traitement de masse ou besoin d’une interface SAP non encore publiée. Le parcours standard ne promet pas de traiter ces exceptions sans expertise. Il précise quand une revue d’architecture ou de sécurité reste nécessaire. L’objectif est d’automatiser les répétitions maîtrisées, pas d’effacer les arbitrages. Une exception fréquente révèle toutefois un besoin à intégrer dans le service plutôt qu’à traiter indéfiniment comme une anomalie.

Le catalogue décrit les limites, le coût, les engagements de support et les conditions de retrait. Une équipe peut choisir le parcours supporté en connaissant ce qu’elle reçoit. Si un produit exige des capacités hors catalogue, le comité décide s’il finance une extension commune, une solution spécifique ou l’abandon du besoin. Cette décision protège la plateforme d’un backlog sans fin où chaque projet ajoute un composant que personne ne souhaite exploiter.

Conserver la cohérence ERP sans interdire les extensions

Une extension ne doit pas devenir une deuxième source de vérité pour les données dont SAP reste propriétaire. Julien fait définir l’identifiant métier, les événements de synchronisation, les champs modifiables et les contrôles de rapprochement. Si l’extension calcule un résultat, le dossier précise comment ce résultat est validé et à quel moment il influence une transaction. L’existence d’une API ne résout ni la propriété de la donnée ni le droit de la modifier.

L’équipe vérifie les limites techniques utiles au pilotage : volumes, quotas, délais d’échange et traitement des erreurs. Une requête qui fonctionne dans la démonstration peut saturer une interface lorsque plusieurs pays l’utilisent. Le test inclut un doublon, une interruption, une reprise et un retard de synchronisation. L’idempotence, c’est-à-dire la possibilité de rejouer un événement sans créer une deuxième transaction, est examinée avec les spécialistes concernés. Le responsable programme porte la nécessité de cette preuve sans prétendre se substituer à l’architecte SAP.

Les mises à jour ERP et les changements de schémas sont suivis dans un contrat d’interface versionné. Un test de non-régression couvre les extensions dépendantes. La plateforme peut faciliter l’exécution de ce test, mais ne peut pas deviner les règles métier absentes du protocole. Le coût d’une extension inclut cette maintenance future. Présenter un développement cloud comme indépendant du cœur ERP alors qu’il dépend de ses données et de ses événements créerait une autonomie fictive.

Les identités et secrets doivent suivre le cycle de vie

Chaque application possède une identité à droits limités, distincte des comptes humains et des autres applications. Les environnements sont séparés et les secrets ne sont pas copiés dans le dépôt de code. La plateforme automatise leur délivrance, rotation et révocation selon les dispositifs retenus. Julien demande une preuve de retrait : lorsque le service est arrêté, les accès, secrets, données temporaires et dépenses associées sont supprimés ou conservés selon une règle explicite.

Le pipeline de livraison intègre des contrôles définis avec la sécurité et l’exploitation. Il peut vérifier configuration, dépendances et présence des éléments de supervision, mais un contrôle automatique vert ne garantit pas que l’usage métier est acceptable. Une dérogation a un propriétaire, une expiration et un motif. Si les équipes contournent fréquemment le parcours, il faut comprendre si elles évitent un contrôle nécessaire ou si le service est trop lent et trop difficile à utiliser.

Le support connaît les frontières : incident d’application, problème de plateforme, indisponibilité du cloud ou interruption SAP. Un ticket ne doit pas tourner entre quatre équipes sans responsable de la coordination. Le service dispose d’un mécanisme d’escalade pour les incidents transversaux. Les journaux sont exploitables pour cette investigation, avec accès et conservation adaptés. Collecter beaucoup de traces sans pouvoir corréler les événements ne produit pas une capacité opérationnelle.

Mesurer le service et sa charge réelle

La plateforme mesure le temps entre une demande admissible et un environnement réellement utilisable, les interventions manuelles, les échecs de déploiement et la satisfaction des équipes sur un parcours défini. Elle distingue adoption volontaire et usage imposé. Un grand nombre d’utilisateurs peut refléter une obligation d’entreprise plutôt qu’une réduction du travail. Julien observe également les équipes qui n’utilisent pas le service et les raisons de cette décision.

Le coût complet inclut équipe plateforme, outillage, consommation cloud, support et activités imposées aux équipes clientes. Le coût par environnement n’est pertinent que si les environnements sont comparables ; le coût par déploiement peut être trompeur si l’on encourage artificiellement de nombreux déploiements sans valeur. Le comité choisit une unité liée au parcours et publie les règles d’allocation. Les capacités communes sont réparties selon des clés explicites, avec les limites du calcul.

Un exemple hypothétique illustre le seuil économique : la plateforme coûte 180 000 euros par an, et évite 300 heures de préparation sur les équipes clientes. Ce constat seul ne démontre pas sa rentabilité. Il faut chiffrer la valeur de la capacité réellement réaffectée, les incidents évités avec des hypothèses prudentes et les coûts qui auraient existé sans plateforme. Si les gains restent faibles, Julien peut réduire le catalogue ou acheter une capacité managée. Maintenir une équipe parce qu’une plateforme a déjà été annoncée n’est pas une décision économique.

Dans la vraie vie : un parcours plus petit mais fini

L’équipe propose initialement un portail couvrant toutes les technologies du groupe. Julien préfère un parcours limité pour une extension SAP et une application documentaire. Deux équipes pilotes l’utilisent jusqu’à la production, avec un observateur différent des concepteurs. Les étapes qui nécessitent une connaissance implicite sont documentées ou automatisées. Les problèmes de droits et d’interface sont résolus avant d’ajouter une nouvelle famille de services.

Le comité accepte l’ouverture lorsque l’équipe plateforme peut assister un utilisateur, diagnostiquer un échec et retirer proprement une application. La date n’est pas la seule condition de passage. Le bilan comprend les exceptions encore manuelles et la charge que chacune impose. La plateforme reste un produit interne : elle doit continuer à justifier son catalogue, retirer les capacités peu utiles et améliorer les parcours dont les utilisateurs dépendent réellement.

Trois contraintes qui changent le catalogue

Sur un site industriel, la connectivité intermittente et les dépendances avec les opérations de production peuvent imposer un mode local et des fenêtres de changement spécifiques. Dans un environnement réglementé, les preuves de changement et de validation doivent rester traçables ; accélérer ne signifie pas contourner les approbations. Pour une organisation internationale, coûts, identités et support doivent suivre les entités et les fuseaux horaires. Une plateforme commune offre des règles communes là où elles sont utiles, et documente les différences là où elles sont nécessaires.

Conserver une décision vérifiable

La preuve de retrait fait partie de ce parcours : environnement supprimé, accès révoqués, facturation arrêtée et données conservées ou effacées selon une règle approuvée. Une plateforme qui sait créer mais ne sait pas retirer accumule une dette de service.

Sources, méthode et limites

Sources primaires consultées le 4 octobre 2026. Le dossier propose une conduite de programme et des critères de preuve ; il n’est pas un guide de configuration SAP ou cloud. Les chiffres sont pédagogiques et les choix d’architecture doivent être validés par les spécialistes.