Entretien avec Antoine Ponssard, Manager ERP Oracle au sein du LAB PREREQUIS
Implémenter Oracle Integration Cloud (OIC) ou reprendre un patrimoine existant : dans les deux cas, l’enjeu est de maîtriser les échanges qui supportent la facturation, les paiements ou la comptabilité.
Antoine Ponssard, Manager ERP Oracle au sein du LAB PREREQUIS, partage son expérience des projets et de l’exploitation. Son fil conducteur : penser la vie des intégrations après leur mise en production, dès la conception.
OIC, du build au run : l’expertise du LAB PREREQUIS – Interview : L’essentiel en 2 minutes 30, en vidéo.
L’entretien complet suit ci-dessous
Au sommaire :
- Pourquoi OIC devient structurant avec ERP Cloud
- Implémenter OIC : du cadrage à la mise en production
- Reprendre et exploiter un patrimoine OIC existant
- Ce qui fait la différence sur un projet OIC
Pourquoi OIC devient structurant avec ERP Cloud
Quel est ton rôle aujourd’hui autour d’OIC ?
Je pilote les activités de tierce maintenance applicative (TMA) Oracle et je porte nos offres OIC. Mon rôle est de faire le lien entre les projets, les équipes techniques, les enjeux fonctionnels et l’exploitation.
Notre offre couvre l’implémentation de la plateforme OIC, le développement des intégrations, puis leur support et leurs évolutions. Ce que nous apprenons en exploitation nourrit nos choix de conception.
Pourquoi OIC devient-il stratégique avec ERP Cloud ?
Avec ERP Cloud, l’ERP doit communiquer avec les outils Achats, les plateformes de dématérialisation, les systèmes RH et les applications métier, parfois encore EBS ou d’autres systèmes historiques.
OIC est le point de passage de ces échanges : c’est là que se décide quand un traitement part, sous quelle forme la donnée arrive dans l’application destinataire, et ce que l’on voit quand quelque chose ne passe pas.
Derrière un flux, il y a une facture, un fournisseur ou une écriture comptable. L’enjeu dépasse donc la connexion entre deux applications : il faut suivre le résultat de l’échange et comprendre ce qui se passe lorsqu’un traitement n’aboutit pas.
Implémenter OIC : du cadrage à la mise en production
Comment se déroule une implémentation d’OIC ?
Il faut distinguer la mise en place de la plateforme et le développement des flux. Pour un client qui démarre, notre offre porte aussi sur la préparation et la configuration d’OIC, de ses environnements et de ses connexions au système d’information.
Le projet commence par le cadrage : applications à connecter, processus concernés, types de flux, volumes et contraintes de sécurité. Cela permet de définir l’architecture cible, les services OCI nécessaires, le dimensionnement et le planning.
Vient ensuite la préparation des environnements de développement, de test et de production : mise en place et configuration des instances OIC, connectivité avec le SI, accès et droits, sécurisation. Les compétences OIC et OCI sont mobilisées selon les besoins, avec les équipes du client.
Nous pouvons ensuite prendre en charge le développement des intégrations, les tests techniques et la recette métier, puis la préparation et la coordination de la mise en production. La supervision initiale et l’accompagnement après démarrage préparent le relais vers le support et la TMA.
L’implémentation ne se limite donc pas à ajouter un flux dans un OIC déjà en place : elle comprend aussi les fondations techniques et l’organisation qui permettront d’exploiter les intégrations dans la durée.
Comment choisissez-vous l’architecture adaptée ?
On part d’abord du besoin métier et des contraintes du SI existant. Quand les applications le permettent, nous privilégions les échanges par API, tout en conservant les traitements par fichiers lorsqu’ils sont adaptés au contexte du client.
Un traitement quotidien peut rester planifié. L’approche événementielle devient pertinente lorsque plusieurs traitements doivent réagir indépendamment à un même événement métier. Dans ce modèle, le système qui génère l’événement le publie une seule fois, tandis que chaque traitement intéressé le récupère et l’exploite de son côté.
Le temps réel ne constitue pas une finalité en soi : il doit répondre à un besoin métier concret. Quelle que soit l’option retenue, l’architecture doit anticiper les indisponibilités, la gestion des doublons et les mécanismes de reprise.
Que prévoir dès la conception des intégrations OIC ?
Il faut prévoir la supervision, la gestion des erreurs et les modalités de reprise. C’est le principe « build for run » : penser l’exploitation dès la conception.
Dans OIC, les identifiants métier permettent de retrouver une exécution à partir d’une information fonctionnelle. Pour un flux de factures, l’équipe support peut ainsi rechercher un numéro de facture plutôt qu’un identifiant technique.
Il faut aussi vérifier le résultat métier, pas seulement le statut technique. Un flux peut apparaître terminé alors que certaines factures n’ont pas été intégrées ; il faut donc exploiter les retours de traitement de l’ERP.
Les alertes et les procédures de reprise doivent aussi être prévues, avec des contrôles pour éviter qu’un rejeu ne crée des doublons. Ce qui paraît secondaire pendant le développement devient déterminant en production.
Reprendre et exploiter un patrimoine OIC existant
Comment les intégrations évoluent-elles dans le temps ?
De nouveaux flux s’ajoutent et les flux existants sont adaptés aux besoins. Le nombre d’intégrations ne dit pas tout de leur maintenabilité : leur organisation et la connaissance partagée comptent aussi.
Au fil des évolutions, on peut retrouver de la logique dupliquée, des conventions différentes ou une documentation qui ne suit plus. Il devient alors plus difficile de comprendre les dépendances et de modifier un flux.
Le travail consiste à maintenir des règles communes, des composants réutilisables et une traçabilité des changements, pour que la connaissance ne repose pas sur quelques personnes.
Comment reprendre un patrimoine OIC existant ?
On commence par comprendre ce qui existe, pas par tout réécrire.
Il faut identifier les applications, les intégrations critiques, leurs dépendances, les volumes, les règles de gestion et les modes de traitement des erreurs.
Ensuite, on détermine ce qui doit être rationalisé : une chaîne trop complexe, de la logique dupliquée, une gestion d’erreurs insuffisante ou une documentation absente.
C’est précisément le type de démarche que nous menons aujourd’hui chez un client international, sur un patrimoine d’environ 100 intégrations OIC et près de 50 000 fichiers traités chaque mois. L’enjeu n’est pas de tout reconstruire, mais de reprendre la maîtrise de l’existant, de le fiabiliser et de continuer à le faire évoluer.
Comment se passe le traitement d’un incident ?
On commence par qualifier l’anomalie : quel traitement est concerné, quelles données sont touchées et quel est l’impact métier ?
On analyse ensuite les exécutions et les retours des applications pour localiser la cause. Une erreur visible dans OIC peut venir d’une donnée, de l’ERP, d’une application connectée, d’un certificat ou du réseau.
Selon le diagnostic, on mobilise les compétences OIC, ERP Cloud, OCI, bases Oracle ou administration systèmes. Le traitement de l’incident est tracé et la reprise est organisée selon le flux concerné. Le suivi porte aussi sur le résultat dans l’application destinataire, pas seulement sur la disparition de l’erreur.
A titre d’exemple, sur l’un des environnements que nous exploitons, une montée de version d’une application amont a entraîné plus de 6 000 factures en anomalie.
Il fallait identifier l’origine du problème et effectuer les corrections avant la campagne de paiement fournisseurs. Le traitement demandait une connaissance de la chaîne de bout en bout, au-delà du seul flux OIC.
Cet exemple montre pourquoi la qualification de l’incident doit tenir compte de l’échéance métier, et pas seulement de sa manifestation technique.
Comment s’organise le travail en TMA ?
Le point central, c’est l’arbitrage. Comme responsable de TMA, je coordonne les compétences — OIC, ERP Cloud, OCI, bases Oracle — et je tranche les priorités entre le fonctionnement courant et les projets, en tenant compte des rôles de chacun dans le dispositif du client. Le ticketing et le suivi des changements permettent de savoir ce qui a été demandé, traité et mis en production.
Le travail comprend aussi l’analyse des erreurs récurrentes, l’amélioration de la documentation et la simplification de certains flux. Ces actions sont planifiées avec le client, au même titre que les nouveaux besoins.
Ce qui fait la différence sur un projet OIC
Quelles erreurs de conception rencontrez-vous le plus souvent ?
Construire des flux qui concentrent trop de traitements, au point de devenir difficiles à comprendre ou à reprendre. Une orchestration doit rester lisible et pouvoir évoluer sans remettre toute la chaîne en cause.
L’autre écueil est de reporter les questions d’exploitation après la mise en production. Si la reprise, les contrôles et les informations utiles au support n’ont pas été prévus, il faut les ajouter lorsque les incidents surviennent. C’est précisément ce que nous cherchons à anticiper pendant le projet.
Que regardez-vous pour évaluer la maîtrise d’un patrimoine OIC ?
Quelques questions donnent un premier repère : connaît-on les flux critiques ? Peut-on retrouver une transaction métier et comprendre son résultat ? Les procédures de reprise et la documentation permettent-elles à l’équipe de prendre le relais ?
Pour un projet d’implémentation OIC, le point de départ est le cadrage de l’architecture, des environnements et de leur exploitation. Pour une plateforme déjà en production, c’est l’état des lieux du patrimoine. Dans les deux cas, il s’agit de définir les priorités et le périmètre de l’accompagnement : mettre en place OIC ou reprendre l’existant, en préparant sa vie en production.
Avec le recul, qu’est-ce qui fait vraiment la différence sur un projet OIC ?
Je dirais la capacité à penser au-delà de la mise en production. Une intégration doit répondre au besoin métier, mais aussi être exploitable dans la durée. C’est ce qui relie finalement nos deux types d’intervention : l’implémentation d’un nouvel environnement et la reprise d’un patrimoine existant. Dans les deux cas, on cherche à construire quelque chose que le client pourra réellement maîtriser.
