Quand la donnée fournisseur change, les validations et l’ERP suivent.
Transdev s’appuie sur ROK pour fiabiliser son Référentiel Fournisseur National et orchestrer chaque demande jusqu’à CODA-FI.
Cas client
Référentiel fournisseur · Approbations · Contrôle IBAN · CODA-FI
Création, modification, désactivation ou réactivation : ROK applique les bonnes règles, déclenche les validations et sécurise les contrôles.
Une gouvernance du référentiel fournisseur intégrée aux outils existants, sans remplacer l’ERP ni les sources de données du groupe.
Le parcours en un regard
- Demande fournisseur
01
- Données et justificatifs
02
- Approbations
03
- Contrôles
04
- CODA-FI et preuves
04
Un référentiel critique
à l’échelle d’un grand groupe
À l’échelle d’un groupe international, la fiabilité de la donnée fournisseur conditionne les achats, les paiements et le contrôle interne.
14 millions
de passagers transportés chaque jour
10,44 Md€
de chiffre d’affaires en 2025
107 048
collaborateurs
19 pays
dans le périmètre international du groupe
ROK chez Transdev
Un référentiel fournisseur
déployé à grande échelle
100 sites
concernés en France
800 users
sur le périmètre ROK
300 sociétés
au déploiement initial
4 flux
création · modification · désactivation · réactivation
Un référentiel éclaté ne sécurise pas
le cycle fournisseur
Un référentiel fournisseur n’est pas seulement une base de données. C’est un processus de gouvernance reliant données, responsabilités, contrôles et systèmes.
01
Des données hétérogènes
Les différentes entités pouvaient appliquer leurs propres pratiques de saisie, avec des formats, des informations et des niveaux de qualité variables.
02
Un risque de doublons
Sans recherche préalable commune ni critères d’unicité suffisamment maîtrisés, un même fournisseur pouvait être référencé plusieurs fois.
03
Des approbations dispersées
Le bon approbateur dépendait notamment de la famille d’achat, du profil du demandeur, de son rattachement géographique et de la nature de la demande.
04
Des informations sensibles
Les coordonnées bancaires, les justificatifs, les conditions de paiement et les données d’identification nécessitaient des contrôles spécifiques.
05
Une traçabilité insuffisante
Les demandes, pièces jointes, décisions, retours pour complément et validations devaient pouvoir être retrouvés dans un historique commun.
06
Une intégration ERP à préserver
Le nouveau dispositif devait s’intégrer à CODA-FI et aux autres outils du groupe sans reconstruire l’ensemble du système d’information.
ROK orchestre le parcours.
CODA-FI conserve le référentiel.
ROK relie les sources, les workflows et les contrôles à CODA-FI, sans remplacer les outils existants.
Sources et contexte
01
Altares et données existantes
Les données d’identification disponibles peuvent être récupérées depuis Altares ou depuis le référentiel existant afin de préremplir la demande et d’éviter une saisie inutile.
Profil du demandeur
Le profil, le pôle géographique et les responsabilités de l’utilisateur déterminent les formulaires auxquels il accède et les actions qu’il peut réaliser.
Pièces justificatives
Kbis, devis, RIB et autres documents restent liés à la demande et au fournisseur concerné.
ROK Solution
02
Formulaires contextualisés
Les champs obligatoires et les règles de contrôle s’adaptent au type de fournisseur, à son pays, à son mode de paiement et au type de demande.
Workflows d’approbation
ROK détermine les acteurs, applique les règles, déclenche les validations et gère les retours pour complément ou les rejets.
Contrôles
Les données sensibles et les coordonnées bancaires peuvent être vérifiées par des règles automatiques, par OCR et, lorsque cela est nécessaire, par un réviseur.
Traçabilité
Chaque intervention, commentaire, décision, statut et document reste rattaché au parcours.
CODA-FI et systèmes connectés
03
Référentiel maître
Après validation, le fournisseur est créé ou mis à jour dans le référentiel maître hébergé dans CODA-FI.
Diffusion
Les informations sont ensuite transmises aux applications clientes concernées selon l’architecture définie par Transdev.
Notifications
Les demandeurs, approbateurs et gestionnaires reçoivent les informations correspondant à l’avancement du parcours.
1
ENTRÉES
Données d’identification · Contexte utilisateur · Justificatifs
Source : Altares
2
ORCHESTRATION
Formulaires · Règles · Workflows · Contrôles · Preuves
Plateforme : ROK
3
RÉFÉRENTIEL
Référentiel maître fournisseur
ERP : CODA-FI
4
DIFFUSION
Données validées vers les systèmes aval
Cibles : applications connectées
Les données validées dans ROK sont transmises à CODA-FI sans demander une nouvelle ressaisie dans l’ERP.
Une demande fournisseur,
un même enchaînement de bout en bout
De la vérification de l’existence du fournisseur à sa création dans CODA-FI, chaque étape utilise le même contexte, les mêmes données et le même historique.
1
Vérifier l’existence du fournisseur
La recherche s’effectue notamment à partir du SIRET, du SIREN, du DUNS, du nom ou du code postal afin de limiter les créations en doublon.
2
Identifier et préremplir
Lorsque les données sont disponibles, ROK récupère les informations d’identification issues d’Altares ou du référentiel existant.
3
Compléter la demande
Le demandeur renseigne les informations manquantes et joint les justificatifs nécessaires : Kbis, devis, RIB ou documents complémentaires.
4
Déterminer le circuit
Le type de fournisseur, la famille d’achat, le profil du demandeur et les règles internes définissent les acteurs à solliciter.
5
Approuver la demande
L’approbateur Achats peut valider, rejeter, réaffecter ou retourner la demande pour complément d’information.
6
Contrôler et enrichir
Le gestionnaire RFN contrôle les données saisies et complète les informations nécessaires à la création ou à la mise à jour du fournisseur.
7
Vérifier les données bancaires
Les données IBAN et le nom du bénéficiaire peuvent être contrôlés automatiquement. Les exceptions sont adressées au réviseur compétent.
8
Mettre à jour et conserver la preuve
Le fournisseur est créé ou modifié dans CODA-FI. Le demandeur est informé et l’ensemble du parcours reste consultable.
Le contexte fournisseur
détermine le circuit d’approbation
Ce qui détermine le circuit
du type de demande
du pôle ou de l’entité concernée
du type de fournisseur
des données effectivement modifiées
du profil du demandeur
de la famille d’achat
des modalités de paiement
du résultat des contrôles précédents
Les acteurs et systèmes mobilisés
01
Demandeur
Recherche le fournisseur, initie la demande, complète les informations et fournit les pièces requises.
02
Approbateur Achats
Contrôle la demande selon la famille d’achat et les règles définies par Transdev.
03
Gestionnaire RFN
Vérifie les données, complète les informations financières et prépare la mise à jour du référentiel.
04
Réviseur IBAN
Intervient lorsque les coordonnées bancaires nécessitent une vérification complémentaire.
05
ROK et CODA-FI
Appliquent les traitements automatiques, mettent à jour le référentiel, notifient les acteurs et conservent la trace.
Quatre
workflows
couvrent
le cycle de vie du fournisseur
Recherche et consultation en entrée, puis quatre workflows pour gérer le cycle de vie du fournisseur.
Création : référencer un nouveau fournisseur
Le demandeur vérifie d’abord que le fournisseur n’existe pas déjà.
Les données disponibles sont récupérées, les justificatifs sont collectés, la demande est approuvée puis contrôlée. Après validation des informations nécessaires, le fournisseur et son code sont créés dans CODA-FI.
Modification : faire évoluer une fiche existante
Le formulaire reprend les informations déjà présentes dans le RFN.
Le workflow déclenche uniquement les contrôles nécessaires à la modification concernée. Une évolution des coordonnées bancaires peut, par exemple, nécessiter une nouvelle validation IBAN, alors qu’une autre modification suit un circuit plus court.
Désactivation : sécuriser l’arrêt d’utilisation
Le demandeur retrouve le fournisseur et précise le motif de la désactivation.
Selon la situation, déréférencement, litige, fraude, liquidation ou changement d’identifiant, le parcours applique les validations et le niveau de blocage appropriés avant de mettre à jour CODA-FI.
Réactivation : réautoriser un fournisseur
Le fournisseur est retrouvé dans le référentiel et le motif de sa réactivation est renseigné.
La demande suit le circuit d’approbation défini, puis la réactivation est appliquée dans le référentiel sans supprimer l’historique précédent.
ROK – formulaire et workflow de création d’un fournisseur dans le RFN Transdev.
Vos flux fournisseurs suivent-ils les mêmes règles dans chaque entité ?
Prenez une création, une modification, une désactivation ou une réactivation réelle.
En 30 minutes, nous identifions avec vous les ruptures entre la donnée fournisseur, les justificatifs, les approbateurs, les contrôles et la mise à jour de l’ERP.
Chaque demande
devient une preuve exploitable
Chaque demande conserve ses étapes, ses acteurs, ses délais, ses décisions et ses justificatifs dans une même trace.
01
Activité et volumétrie
Suivi des demandes de création, modification, désactivation et réactivation par période, type, statut ou périmètre.
02
Délais de traitement
Mesure des délais moyens par étape : approbation, contrôle, attente fournisseur, validation IBAN et traitement global.
03
Achats et contrôle interne
Analyse des demandes rejetées, des motifs, des modifications de données financières et des profils disposant des accès correspondants.
04
Piste d’audit
Conservation des formulaires, pièces jointes, commentaires, décisions, acteurs et étapes du parcours.
05
Export et analyse
Les données de suivi peuvent être filtrées, enregistrées selon différentes préférences et exportées pour des analyses complémentaires.
ROK — suivi des volumes, statuts, délais et interventions du cycle fournisseur.
Après un an d’exploitation, la qualité du Référentiel Fournisseur National de Transdev a été saluée lors de l’audit.
Des gains mesurés
sur le cycle fournisseur
Résultats historiques observés ou estimés sur le périmètre Transdev, à partir de l’activité 2019 et du modèle ROI 2020.
15 545 flux lancés en 2019
Plus de 1 000 demandes fournisseurs par mois
Soit environ 1 295 flux mensuels de création, modification, désactivation ou réactivation sur l’année étudiée.
3,5 jours contre 9 jours
Délai de traitement des demandes
Le délai moyen observé est passé de 9 à 3,5 jours, soit une réduction de 61 % sur le périmètre étudié.
81,91 %
Taux de matching OCR sur les créations
Le taux observé au second semestre 2019 atteignait également 63,67 % sur les demandes de modification.
4 jours gagnés par mois
Temps de contrôle économisé grâce à l’OCR
En moyenne, 374,5 demandes finalisées par mois passaient en contrôle automatique, soit environ 1,3 jour gagné par réviseur pour trois réviseurs.
Environ 200 000 € par an
Gain récurrent estimé
Conclusion du modèle ROI 2020, coût de la prestation déduit. Retour sur investissement estimé : 1,3 an.
Résultats observés ou estimés sur le périmètre historique de référence Transdev. Données d’activité 2019 et modèle ROI 2020. Les résultats peuvent varier selon les volumes, les processus, les contrôles, les ressources et l’architecture en place. Méthodologie détaillée disponible sur demande.
Une même donnée fournisseur,
des responsabilités clairement réparties
Le RFN fournit un cadre commun sans demander à chaque acteur de maîtriser l’ensemble du processus.
01
Pour les demandeurs
Un formulaire guidé, des champs adaptés au contexte et une visibilité sur l’avancement de la demande.
02
Pour les Achats
Des approbations ciblées selon la famille d’achat, le type de fournisseur et les règles définies par l’organisation.
03
Pour les gestionnaires RFN
Une bannette commune, des dossiers complets et la possibilité de concentrer l’intervention humaine sur les contrôles et les exceptions.
04
Pour la Finance et les réviseurs IBAN
Des données bancaires reliées aux justificatifs, avec une orientation automatique vers le contrôle approprié.
05
Pour le contrôle interne et les auditeurs
Une piste reliant les données, les documents, les décisions, les motifs de rejet et les personnes intervenues.
06
Pour la DSI
Une application intégrée au SI existant, avec SSO, interfaces, règles gouvernées et évolutions prises en charge sans remplacement de CODA-FI.
Dans sa propre présentation du projet, Transdev mettait notamment en avant :
L’agilité des équipes ROK · La capacité d’interconnexion · La compétence technique · La stabilité des procédures · Le SSO · La réactivité dans les corrections · La facilité d’administration.
Une application métier
qui évolue sans reconstruire l’ERP
Les formulaires, règles, profils, contrôles et reportings peuvent évoluer avec le processus fournisseur sans reconstruire CODA-FI.
Côté métiers |
adaptation des formulaires ;
évolution des règles de validation ;
gestion des profils et responsabilités ;
ajustement des contrôles et indicateurs.
Côté IT |
interfaces CODA-FI et Altares ;
accès et SSO ;
gestion des environnements ;
support, architecture et sécurité.
Le no-code est ici une capacité d’évolution. La promesse reste la maîtrise du parcours fournisseur, de la donnée initiale à la mise à jour de l’ERP.
Votre référentiel fournisseur suit-il vraiment chaque changement ?
Partez d’une création, d’une modification, d’une désactivation ou d’une réactivation réelle.
En 30 minutes, identifiez les doublons, les ressaisies, les validations, les contrôles et les preuves qui pourraient être mieux orchestrés dans votre environnement.
En savoir plus : Référentiel fournisseur et workflows P2P
Les réponses aux questions les plus fréquentes sur les données fournisseurs, les circuits d’approbation, les contrôles et l’intégration ERP.
ROK remplace-t-il CODA-FI ?
Non. Dans le cas Transdev, CODA-FI reste le système cible hébergeant le référentiel maître. ROK orchestre les demandes, les données, les justificatifs, les validations et les contrôles avant de transmettre les informations validées à l’ERP.
Quels mouvements fournisseurs peuvent être couverts ?
Comment ROK limite-t-il les doublons ?
Avant toute création, le demandeur recherche le fournisseur à partir de critères comme le SIRET, le SIREN, le DUNS, la raison sociale ou le code postal. Les données issues de sources externes peuvent également contribuer à l’identification.
Comment le bon approbateur est-il déterminé ?
Comment les coordonnées bancaires sont-elles contrôlées ?
Les documents et les données bancaires restent rattachés à la demande. Des contrôles automatiques et OCR peuvent être appliqués, puis les cas nécessitant une vérification complémentaire sont adressés au réviseur compétent.
Les équipes peuvent-elles suivre les demandes et les délais ?
Oui. Le suivi peut restituer les volumes, les statuts, les étapes, les acteurs, les délais et les données associées. Les informations peuvent également être filtrées et exportées pour des analyses complémentaires.
Les métiers peuvent-ils faire évoluer les formulaires et les workflows ?
Oui, dans le cadre de la gouvernance définie avec l’IT. Les règles, formulaires, profils, contrôles et restitutions peuvent évoluer sans reconstruire l’ERP.
Le projet impose-t-il de refondre tout le processus purchase-to-pay ?
Non. Le cas Transdev porte principalement sur la composante référentiel fournisseur du cycle purchase-to-pay. ROK la relie aux approbations, aux contrôles et à l’ERP tout en conservant les autres applications dans leur rôle.