Sunopsis est devenu Oracle Data Integrator après son acquisition par Oracle en 2006. La continuité technique se lit encore dans les concepts d’ODI, notamment les Knowledge Modules, les mappings déclaratifs et l’exécution des transformations au plus près de la base cible. Pour un parc existant, la question porte moins sur le changement de nom que sur la capacité à maintenir, documenter et faire évoluer les flux.
En bref
- Sunopsis a apporté à Oracle une approche ELT fondée sur la génération de code dans les moteurs de données plutôt que sur un serveur de transformation central.
- Oracle Data Integrator conserve les objets structurants de cet héritage, dont les modèles, interfaces devenues mappings, scénarios et Knowledge Modules.
- Un inventaire des packages, des agents et des règles de chargement doit précéder toute décision de migration ou de maintien.
- La reprise d’un flux ne garantit pas l’identité des chiffres : les contrôles, rejets et règles de dédoublonnage doivent faire l’objet d’une recette distincte.
Ce contenu s’adresse aux responsables BI et aux chefs de projet qui exploitent encore des flux Sunopsis ou Oracle Data Integrator dans un socle décisionnel. Il traite de l’intégration de données et de la migration des flux ; les choix d’infrastructure, les clauses contractuelles et la protection des données personnelles relèvent d’autres compétences.
Comment Sunopsis est devenu Oracle Data Integrator
Sunopsis a occupé une place particulière dans le paysage français de l’ETL. L’outil ne reposait pas sur le principe habituel consistant à extraire les données, les transformer dans un moteur dédié, puis les charger dans une cible. Son mécanisme privilégiait l’exécution des transformations là où les données étaient destinées à être traitées, en produisant du SQL ou des commandes adaptées au moteur cible. Cette logique est restée au cœur d’Oracle Data Integrator.
Oracle a acquis Sunopsis en 2006 et l’a intégré à sa gamme Middleware. Le positionnement produit a alors changé d’échelle, avec un rattachement plus fort aux bases Oracle, aux applications de gestion du groupe et aux outils d’administration. La trajectoire ne doit pas masquer une continuité concrète pour les équipes techniques : de nombreux référentiels historiques conservent des conventions de nommage, des scénarios et des mécanismes construits à l’époque Sunopsis.
La page produit d’Oracle Data Integrator, consultée en mars 2026, présente toujours l’outil comme une solution d’intégration capable de charger et de transformer dans les entrepôts de données en exploitant la puissance de calcul de la base cible. Cette formulation recouvre le principe historique de push-down. Elle n’implique pas que tous les traitements seront exécutés dans la cible : le comportement dépend du Knowledge Module choisi, de la technologie source et des possibilités réelles du connecteur.
Dans un socle BI ancien, cette distinction explique souvent des écarts de charge mal anticipés. Un flux qui paraît contenir une simple jointure peut générer une table de transit, lancer plusieurs étapes SQL, contrôler les doublons puis appeler un package secondaire. La lecture d’un diagramme ne suffit donc pas. Il faut examiner le scénario généré, les journaux d’exécution et le code produit sur la base.
Pourquoi l’approche ELT a marqué les projets décisionnels
Le modèle ELT déplace la Transformation de données après le Chargement dans une zone gérée par le moteur cible. Dans un entrepôt relationnel, ODI peut ainsi demander à la base d’exécuter les jointures, agrégations, contrôles d’intégrité et insertions. Cette organisation évite de transférer certains volumes vers un serveur ETL séparé, puis de les ramener vers la base de destination.
Le gain n’est jamais automatique. Une transformation poussée vers une base surcharge potentiellement ses ressources au moment des traitements nocturnes. Un chargement qui concurrence les requêtes BI du matin peut dégrader les délais de restitution, même si le flux termine plus vite sur le papier. L’arbitrage doit porter sur les fenêtres d’exécution, les index, les statistiques de tables et les volumes réellement déplacés.
Oracle documente les mécanismes d’ODI 12c, ses mappings, ses agents et ses Knowledge Modules dans sa documentation de développement ODI 12c, consultée en mars 2026. Cette documentation confirme que le Knowledge Module porte une part importante de la stratégie d’exécution. Deux mappings qui affichent la même règle fonctionnelle peuvent donc produire des comportements techniques très différents.
La première difficulté d’une Migration vient de là. Reprendre visuellement les correspondances entre colonnes ne reconstitue pas nécessairement le mécanisme de contrôle, la stratégie de purge ou la journalisation. Un flux d’Extraction de commandes peut, par exemple, traiter des annulations par suppression physique dans une table intermédiaire plutôt que par mise à jour. Cette règle ne se lit pas toujours dans le mapping principal.
Avant toute réécriture, il faut conserver les artefacts qui expliquent le comportement réel : exports de référentiel, code des procédures, journaux de sessions, paramètres d’agents et ordonnancement externe. Le nom Oracle Data Integrator a changé la couverture commerciale du produit, pas la nécessité de relire les décisions techniques prises dans les flux historiques.
Quels objets Sunopsis et ODI doivent être inventoriés avant une migration
Un inventaire fiable commence par les objets exécutables, non par les seuls projets visibles dans ODI Studio. Un parc peut contenir des dizaines de packages non appelés depuis des années, mais aussi un scénario autonome lancé par un ordonnanceur externe. Ce dernier n’apparaît pas forcément dans la hiérarchie fonctionnelle consultée par les équipes BI.
Le périmètre minimal comprend les modèles physiques et logiques, les datastores, les mappings, les packages, les scénarios, les variables, les séquences, les procédures, les Knowledge Modules et les agents. Les droits d’accès au référentiel doivent aussi être relevés. Une variable globale modifiée par un traitement d’administration peut influer sur plusieurs chargements sans être appelée dans leur package principal.
Le tableau suivant croise les objets ODI avec les éléments à contrôler et le risque principal lors d’une reprise. Il s’appuie sur la documentation Oracle ODI 12c consultée en mars 2026 et doit être complété par les logs de votre environnement. Aucun accès à un référentiel Sunopsis ou ODI client n’a été utilisé pour cet article.
| Objet du référentiel | Élément à relever | Risque lors de la migration | Preuve à conserver |
|---|---|---|---|
| Mapping ou interface | Sources, filtres, jointures, tables de transit et cible | Une règle de sélection peut disparaître si elle est portée par un filtre technique | Export XML et code généré |
| Knowledge Module | Version, options actives, stratégie d’intégration et contrôles | Le chargement peut produire un SQL différent sur la cible | Copie du KM et journal de session |
| Package et scénario | Enchaînements, conditions, variables et relances | Une dépendance d’exécution peut être omise | Scénario compilé et calendrier d’ordonnancement |
| Agent ODI | Topologie, exécution locale ou distante, ports et contextes | Le flux fonctionne en développement mais échoue en production | Paramètres d’agent et journaux techniques |
| Procédure | Commandes SQL, scripts système et appels externes | Une purge ou un contrôle métier reste invisible dans le mapping | Texte intégral de la procédure |
La source fonctionnelle ne remplace pas cette lecture. Dans les socles construits progressivement, les règles de gestion se déplacent souvent dans les procédures, les options de Knowledge Modules ou les vues de la base. Un package qui semble ne faire que lancer trois mappings peut porter, entre deux étapes, un contrôle de volumétrie qui bloque le chargement si le nombre de lignes varie au-delà d’un seuil.
Comment mesurer l’usage réel des flux et des scénarios
Un flux présent dans le référentiel n’est pas nécessairement un flux utile. La mesure doit porter sur douze mois glissants afin de couvrir les traitements mensuels, trimestriels et annuels. Les journaux d’exécution ODI, les fichiers de l’ordonnanceur et les traces de la base doivent être rapprochés. Une rétention de quatre-vingt-dix jours est insuffisante pour décider qu’un scénario annuel peut être supprimé.
La même méthode s’applique aux restitutions dépendantes de ces chargements. Un infocentre peut survivre techniquement alors que les rapports qui l’utilisent ne sont plus consultés. La démarche décrite pour identifier les rapports BI non consultés permet de relier l’usage des rapports à celui des alimentations qui les rendent possibles.
La décision n’est pas binaire. Un flux peu exécuté peut alimenter une clôture annuelle ou une exigence d’audit interne. Il doit alors être classé comme critique malgré sa faible fréquence. À l’inverse, un chargement quotidien de table de travail sans consommateur identifié mérite d’être arrêté avant toute reprise, après validation des responsables métier concernés.
Un inventaire exploitable relie donc chaque scénario à sa fréquence, sa dépendance amont, sa cible, son propriétaire et son consommateur. Cette traçabilité prépare le calcul de charge. Sans elle, les estimations assimilent à tort un flux de copie de fichier à une chaîne de consolidation comportant plusieurs règles de Transformation de données.
Comment les Knowledge Modules structurent l’automatisation dans Oracle Data Integrator
Les Knowledge Modules constituent la différence pratique la plus visible entre ODI et des outils ETL fondés sur un moteur de transformation autonome. Ils définissent le code et les opérations nécessaires pour extraire, intégrer, contrôler ou journaliser les données. Un LKM organise le chargement depuis une source, un IKM pilote l’intégration vers la cible, tandis que les CKM contribuent aux contrôles de cohérence.
Cette modularité facilite l’Automatisation des flux quand les conventions sont stabilisées. Elle devient un risque lorsque chaque équipe copie puis modifie un Knowledge Module pour répondre à un incident local. Après plusieurs années, deux flux apparemment équivalents peuvent utiliser des variantes différentes d’un même IKM, avec des règles de mise à jour, de suppression ou de gestion des doublons incompatibles.
Oracle indique, sur sa page produit consultée en mars 2026, que la bibliothèque de Knowledge Modules et la conception déclarative servent à connecter des sources et cibles variées. Il faut lire cette promesse dans son périmètre technique. Un connecteur disponible ne reconstitue ni le modèle de données, ni les conventions de qualité, ni les décisions qui ont conduit à accepter certains rejets dans le socle source.
Ce qui doit être comparé entre un flux source et son équivalent cible
La comparaison doit commencer par les lignes traitées. Pour chaque traitement, relevez le nombre de lignes lues, écartées, insérées, mises à jour et supprimées. Ces compteurs doivent être archivés par date d’exécution, avec la requête ou le scénario qui les produit. Une différence de cinquante lignes sur cinq millions n’a pas le même traitement qu’une différence de cinquante lignes sur un référentiel de clients actifs.
Les montants nécessitent un niveau de contrôle supplémentaire. La somme d’un chiffre d’affaires peut varier parce que les annulations sont filtrées, parce qu’une devise est convertie à une date différente, ou parce que la granularité de chargement a changé. Une tolérance chiffrée doit être définie par indicateur et validée avec son propriétaire. Elle ne se déduit pas de la seule précision technique d’un outil.
La reprise d’un mapping sans compréhension du Knowledge Module échoue fréquemment sur les chargements incrémentaux. Une option qui vide une table de transit avant l’intégration ou qui met à jour une clé technique change le résultat final. Le développeur qui ne reprend que les colonnes source-cible restitue la structure, mais pas l’opération de chargement.
Une analyse de Migration doit également examiner les mécanismes d’erreur. Les tables de rejets, les seuils de contrôle et les alertes sont parfois les seuls dispositifs qui signalent une rupture de source. Supprimer ces éléments au motif qu’ils ne figurent pas dans le modèle fonctionnel revient à perdre un dispositif de surveillance construit au fil des incidents.
ODI peut s’intégrer à Oracle GoldenGate pour des besoins de synchronisation et de réplication, comme le décrit la documentation Oracle GoldenGate consultée en mars 2026. Cette association ne doit pas être confondue avec un remplacement automatique d’un batch ODI. GoldenGate traite la réplication ; un package peut contenir des calculs, des enrichissements et des règles BI qui restent à reprendre et à tester.
Le point de contrôle utile consiste à comparer un cycle complet, de l’Extraction jusqu’aux tables consommées par les rapports. Un flux correctement exécuté n’est pas une preuve suffisante : il doit aussi produire des volumes et des montants expliqués.
Comment chiffrer la migration d’un parc Sunopsis ou Oracle Data Integrator
La charge de migration ne se calcule pas en comptant les interfaces ou les mappings. Un objet de cent lignes peut contenir une procédure SQL, une gestion d’erreur spécifique et cinq dépendances externes. À l’inverse, plusieurs mappings de copie homogène peuvent être repris à partir d’un modèle unique. Le découpage par complexité est donc plus utile que le décompte brut.
Le calcul ci-dessous donne un exemple de cadrage, non un tarif ni un engagement de délai. Il concerne un parc de 120 flux inventoriés, composé de 60 flux standards, 40 flux intermédiaires et 20 flux complexes. Les ratios correspondent à une reprise fonctionnelle et technique hors recette métier, hors formation, hors reprise des habilitations et hors correction de qualité dans les sources.
| Catégorie de flux | Volume retenu | Ratio de reprise | Calcul de charge |
|---|---|---|---|
| Flux standard | 60 | 8 heures par flux | 480 heures |
| Flux intermédiaire | 40 | 24 heures par flux | 960 heures |
| Flux complexe | 20 | 56 à 80 heures par flux | 1 120 à 1 600 heures |
| Total reprise technique | 120 | Selon complexité observée | 2 560 à 3 040 heures |
Les ratios sont des hypothèses de cadrage établies pour cet exemple et non une donnée éditeur. Ils supposent que les sources sont accessibles, que les scénarios peuvent être exportés et que les règles de gestion sont retrouvées. Ils excluent explicitement la recette, le double run, la remédiation des écarts et le travail sur les restitutions BI. Toute estimation présentée à une direction doit afficher ces exclusions.
Quand faut-il reprendre et quand faut-il reconstruire
Sur un parc de moins de cent flux dont une part élevée n’est plus exécutée, la reconstruction est souvent préférable à la reprise exhaustive. Le bénéfice ne résulte pas d’un outil neuf, mais de la suppression documentée des flux sans consommateur et de la réécriture des règles réellement utilisées. Cette orientation doit être refusée si les règles sont inconnues, si les journaux sont incomplets ou si la période de recette ne permet pas de couvrir les cycles annuels.
Au-delà de plusieurs centaines de flux avec des dépendances nombreuses, la reprise progressive devient plus défendable. Elle permet de conserver des chaînes critiques pendant que les domaines plus simples sont réorganisés. Le risque est alors de déplacer sans les comprendre des procédures anciennes. Le contrôle de chaque règle dans les données chargées reste obligatoire.
Les coûts de licences ne doivent pas être mélangés à la charge de chantier. Oracle renvoie les modalités de licence et les éléments techniques vers son espace Oracle Data Integrator, consulté en mars 2026, mais les montants réellement facturés dépendent du contrat, des métriques et des remises négociées. Sans devis daté et sans unité de facturation explicitée, aucun coût de licence ne doit être inscrit dans un dossier d’arbitrage.
Une cible non Oracle peut aussi être étudiée si elle correspond aux usages du parc. Le sujet ne consiste pas à opposer des marques de façon abstraite, mais à vérifier la reprise des chaînes existantes, des rapports et des contraintes d’administration. La comparaison entre Power BI, Qlik Sense et BusinessObjects éclaire la partie restitution ; elle ne remplace pas l’analyse des flux d’intégration qui alimentent ces outils.
Le chiffrage devient défendable lorsqu’il relie chaque heure à un objet recensé, une hypothèse et une exclusion. Un total global sans inventaire ne résiste pas au premier flux complexe découvert pendant la recette.
Comment organiser la recette après une migration Oracle Data Integrator
La recette d’un flux Oracle Data Integrator ne doit pas s’arrêter à l’absence d’erreur dans le journal de session. Une exécution verte indique que le scénario est allé à son terme selon les contrôles qu’il contient. Elle ne prouve ni que le périmètre fonctionnel est identique, ni que les agrégats utilisés dans les rapports BI répondent à la règle attendue.
Le protocole commence par la constitution d’un jeu de contrôles. Pour chaque domaine, retenez des compteurs de lignes, des sommes de mesures, des répartitions par statut, des échantillons de clés et les rejets. Les requêtes de comparaison doivent être versionnées. Elles constituent la preuve permettant d’expliquer un écart plusieurs semaines après une bascule.
La méthode de protocole de migration BI peut être appliquée aux alimentations ODI : définir les indicateurs avant la bascule, figer les périmètres de comparaison, expliquer les écarts puis obtenir une validation formelle. Le double run est utile lorsque l’ancien et le nouveau traitement peuvent alimenter deux zones séparées pendant une période suffisamment longue.
Quels écarts doivent bloquer une mise en production
Un écart bloquant est un écart non expliqué sur un indicateur dont dépend une décision de pilotage, une clôture ou un contrôle. Il peut être faible en valeur absolue. Une différence de deux clients actifs peut être bloquante si elle provient d’un filtre sur le statut et change une liste de relance. À l’inverse, un écart de date lié à un décalage de traitement peut être acceptable si son origine, son impact et son retour à la normale sont documentés.
Les règles de tolérance doivent être exprimées en unités métier. Une tolérance de 0,1 % sur un montant global ne protège pas contre une erreur concentrée sur une filiale, une gamme de produits ou une devise. Les contrôles doivent donc croiser les mesures avec des dimensions significatives. Cette granularité réduit le risque d’accepter un total juste obtenu par compensation d’erreurs opposées.
Les rejets méritent une attention spécifique. Un nouveau mapping peut charger le même volume final que l’ancien tout en rejetant des lignes différentes. Ce cas survient lorsque le traitement des clés inconnues, des dates invalides ou des doublons a changé. Le rapprochement doit inclure les tables de rejet et non seulement les tables de destination.
La gouvernance des métadonnées peut aider à documenter les chaînes de transformation. Oracle décrit l’intégration d’ODI avec ses fonctions de gestion de métadonnées et de lignage sur sa documentation produit, consultée en mars 2026. Cet outillage ne remplace pas la validation métier. Il fournit une trace des relations entre objets, mais il ne décide pas si une règle de calcul répond encore au besoin de gestion.
Les équipes doivent également identifier les rapports touchés par chaque chargement. Une alimentation de référentiel peut être utilisée par plusieurs univers ou modèles sémantiques. Dans les environnements BusinessObjects, la règle peut rester invisible dans le Webi si elle est portée par un objet d’univers, une condition ou un contexte de requête. La recette doit alors suivre le chemin complet, de la source au rapport.
La bascule devient possible lorsque les écarts sont classés, expliqués, acceptés ou corrigés, et que le retour arrière reste praticable. Avant d’arrêter l’ancien scénario, conservez les exports de référentiel, les journaux comparatifs et les requêtes de contrôle : ce sont eux qui permettront de traiter le prochain écart sans reconstituer l’historique.
Sunopsis et Oracle Data Integrator désignent-ils le même outil ?
Oracle Data Integrator a repris l’héritage technique de Sunopsis après l’acquisition de l’éditeur par Oracle en 2006. Les versions, l’administration et le périmètre de support ont toutefois évolué ; un inventaire précis de votre version et de vos objets reste nécessaire.
Quelle différence entre ETL et ELT dans ODI ?
Dans une logique ELT, le chargement intervient avant une part importante des transformations, exécutées dans le moteur de données cible. ODI s’appuie notamment sur les Knowledge Modules pour générer les opérations adaptées aux technologies concernées.
Faut-il migrer tous les scénarios ODI existants ?
Non. Les scénarios doivent être classés selon leur fréquence, leurs dépendances, leur propriétaire et leurs consommateurs. Un scénario peu exécuté peut rester critique, tandis qu’un flux quotidien sans usage confirmé peut être arrêté après validation.
Comment prouver que la migration des flux est acceptable ?
La preuve repose sur des comparaisons versionnées : volumes lus et chargés, rejets, sommes de mesures, répartitions métier et échantillons de clés. Les écarts doivent être expliqués et acceptés selon une tolérance définie par indicateur.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
