🤝 Devenir partenaire
🚘 En tant qu'opérateur de covoiturage
3 étapes pour s'interfacer au Registre de Preuve de Covoiturage
Étape N°1 - Validation les CGU
Vous trouverez nos conditions générales d'utilisation (CGU) en ligne.
Merci de nous indiquer par courriel sur contact@covoiturage.beta.gouv.fr votre acceptation de ces CGU.
Qui doit accepter les CGU ?
Celui qui demande et accepte les CGU engage sa structure. Charge à lui ou à elle de prendre ses responsabilités.
Étape N°2 - Transmission des pièces administratives et du dossier technique
Conformément aux CGU nous vous invitons à nous communiquer :
Les pièces d’identification de la personne :
document d’identité pour les personnes physiques ;
justificatif de l’inscription à un registre (commerce, répertoire des métiers ou équivalent) pour les personnes morales ;
Les renseignements suivants :
Identité délégué à la protection des données (Nom, Prénom, Email) ➡️ définition CNIL
Identité responsable de traitement (Nom, Prénom, Email) ➡️ définition CNIL
Identité responsable technique (Nom, Prénom, Email, N° téléphone)
Un RIB.
Un logo à mettre sur notre site covoiturage.beta.gouv.fr
Enfin le dossier technique
confidentiel, ce document a pour objectif la description complète des moyens et mécanismes techniques engagés par l'opérateur pour prouver la mise en relation, la réalisation d’un covoiturage et l’identité d’un covoitureur (cf. les classes de preuves) et les dispositifs de lutte contre la fraude. Pour le compléter, suivre les étapes suivantes :
se créer un compte sur le site démarches-simplifiées.
initier le formulaire (qui sera automatiquement enregistré comme brouillon)
récupérer le document technique « RPC_NomOperateur_DossierTechnique_aaaammjj »
le compléter en se référent au document "Classes&Résultat_V2.2" en lien également sur démarches-simplifiées
et dernière étape : enregistrer le dossier technique complet sur démarches-simplifiées
Le RPC fera une relecture de ce dossier technique et se réserve la possibilité de déclencher des audits de contrôle à tout moment.
Étape N°3 - Interfacage avec l'API Registre de Preuve de Covoiturage
3.1 Se connecter à l'environnement de pré-production
Nous vous ouvrons un accès à l'environnement de pré-production du Registre de preuve de covoiturage afin que puissiez tester l'envoi de vos preuves de covoiturage.
Vous allez recevoir un email vous permettant de vous connecter à votre compte de pré-production : app.demo.covoiturage.beta.gouv.fr
une fois conecté à votre interface, 1. cliquer sur la roue cranntée, 2. cliquer sur l'onglet "API" 3. enfin cliquer sur le bouton "Créer une application" et récupérer votre Tokenn d'authenntification.
en cas de questions techniques, écrivez au support : technique@covoiturage.beta.gouv.fr
Une fois que vous aurez réalisé vos tests sur l'environement de pré-production, contactez nous pour que l'on vous ouvre un accès sur l'environnemet de production.
3.2 Se connecter à l'environnement de production
Nous vous ouvrons donc un accès à l'environnement de production afin d'y faire converger vos preuves de covoiturage.
Vous allez recevoir un email vous permettant de vous connecter à votre compte de production : app.demo.covoiturage.beta.gouv.fr
Voir les étapes décrites dans le paragraphe 3.1 afin de récupérer votre token d'authentification.
en cas de questions techniques, écrivez au support : technique@covoiturage.beta.gouv.fr
❗ Nous respectons la protection de la vie privée. Cliquez ici pour consulter notre approche.
Retrouvez notre documentation technique complète à destination des partenaires et contributeurs sur tech.covoiturage.beta.gouv.fr.
Cadre juridique
Cette partie n'est pas spécifique aux opérateurs partenaires des services mis en œuvre par l'équipe covoiturage.beta.gouv.fr. Il s'agit d'une présentation du cadre juridique applicable à l'ensemble des opérateurs de plateforme de covoiturage.
En 2021 la Direction de la législation fiscale (DLF) à Bercy a été saisi par la DGITM afin de clarifier l'incertitude juridique entre les textes et la doctrine fiscale (BOFIP). En effet, la sphère fiscale prévoit une "mesure de tolérance" pour le cas particulier des activités de partage de frais ou de vente entre particuliers de biens mentionnés au II de l'article 150 UA du CGI.
Dans le cadre de l'article 242 bis du code général des impôts (CGI), les opérateurs de plateforme de mise en relation par voie électronique dans le cadre du covoiturage sont dans l'obligation de déclarer les montants totaux bruts des transactions réalisées par chaque utilisateur qui remplirait les deux critères :
Conducteur percevant plus de 3 000€ sur une année fiscale ;
20 trajets réalisés sur l’année fiscale ou plus.
Concernant spécifiquement la vérification de l’identité et les obligations de la part des opérateurs on retrouve deux obligations :
Obligation générale de vérification de l’identité de vos utilisateurs (KYC - Know Your Customer) ;
Obligation particulière dès lors que le total des transactions réalisées via la plateforme est supérieur ou égal à 1 000€. Pour les particuliers, la plateforme est alors tenue :
Soit de vérifier les noms de famille ou d'usage, prénoms, date de naissance de l'utilisateur, notamment sur présentation par l'utilisateur d'une copie d'une pièce d'identité ;
Soit d’indiquer à l'administration le numéro d'inscription au fichier de simplification des procédures d'imposition (SPI) de l'utilisateur, après en avoir vérifié la structure, le format et l'algorithme.
➡️ L'étude de ces mesures a donné lieu à la constitution d'un chantier sur un cadre de confiance lié à la preuve d'identité.
Foire aux questions
Est-ce que le passager est concerné par cette réglementation ?
Ces critères s'entendent au niveau de l'utilisateur, c'est-à-dire la personne qui propose le trajet (conducteur), seule personne à figurer dans le fichier. Les passagers n'entrent pas dans le champ de l'obligation déclarative prévue par l'article 242 bis du CGI.
Le Code Général des Impôts (CGI) mentionne le terme transaction, qu’est-ce qu’une transaction ?
La transaction a plusieurs définitions (juridiques ou grand public) selon le contexte dans laquelle on l’observe (contentieux, commercial, informatique, etc.). En l’espèce le terme n’est pas précisément défini en droit. La loi fait référence “aux transactions commerciales” entre les utilisateurs de plateforme et soumet l’opérateur à une obligation d’information pour “chacune des transactions” effectuées. Cette rédaction laisse supposer qu’à chaque contrat conclu entre vos utilisateurs, vous devez leur soumettre l’information relative aux conditions fiscales et sociales.
Là encore, la doctrine fiscale semble donner une interprétation plus souple : “les opérateurs de plateforme sont tenus de communiquer lors de chaque transaction au vendeur, au prestataire ou aux parties à l’échange ou au partage d'un bien ou d'un service, lorsque ceux-ci ont perçu des recettes ou revenus par l'intermédiaire de la plateforme, une information loyale, claire et transparente sur les obligations fiscales et sociales qui incombent aux personnes qui réalisent des transactions par leur intermédiaire.”
L’obligation consiste en réalité à informer de manière précise et systématique vos utilisateurs ; ainsi, “cette obligation vaut également pour les opérateurs qui n'ont pas connaissance du montant payé mais qui pour autant ont connaissance de la conclusion d'une transaction dès lors qu'ils transmettent à leurs utilisateurs un document pouvant porter cette mention.”
D’un point de vue strictement juridique, l’information des utilisateurs doit être systématique, à chaque transaction conclue par l’intermédiaire de la plateforme, pour les utilisateurs qui perçoivent des revenus. Compte-tenu des spécificités du covoiturage, il est envisageable qu’une mention claire et précise lors du versement puisse être tolérée. Cette question a également été soulevée du côté des services fiscaux, en attente de clarification.
En considérant une transaction comme un flux financier, si ce flux est mensualisé à défaut d’être par trajet, peut-on considérer qu’il s’agit d’une transaction unique ?
Dans le cas spécifique du covoiturage, une transaction correspond à un trajet entre un conducteur et un unique passager. Le BOI-BIC-DECLA-30-70-40-10 précise qu'une transaction est réputée réalisée dès lors que les parties s'entendent, au travers d'un dispositif technique offert par l'opérateur de plateforme, sur les termes et conditions de la vente d'un bien, de la fourniture d'un service, de l'échange ou du partage d'un bien ou d'un service.
Les montants perçus sont-ils bien uniquement ceux dont la plateforme a connaissance et dont le transit a été effectué via ses services ?
Oui. Les dispositions du CGI qui prévoient la transmission d'informations ne s'appliquent qu'à raison de transactions réalisées par son intermédiaire et dont la plateforme a connaissance. Tel n'est pas le cas d'une transaction réalisée de la main à la main.
Le montant des incitations est-il libre ou limité ?
Décret n° 2020-678 du 5 juin 2020 relatif à la nature des frais de covoiturage et aux conditions de versement d'une allocation par les autorités organisatrices En dehors de la dérogation prévue au septième alinéa de l'article L. 1231-15 et au treizième alinéa de l'article L. 1241-1, l'allocation versée au conducteur par une autorité organisatrice en application du cinquième alinéa de l'article L. 1231-15 et du onzième alinéa de l'article L. 1241-1 ne peut excéder les frais de déplacement engagés par celui-ci, tels que définis à l'article R. 3132-1, déduction faite des sommes éventuellement versées par les passagers à ce même conducteur. : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000041963883/
Il est ainsi recommandé à ces derniers de fixer des offres de covoiturage inférieures ou égales à 0,20€/km par passager, au regard du barème fiscal maximal à 0,60€/km : https://www.ecologie.gouv.fr/covoiturage-en-france-avantages-et-reglementationen-vigueur
Comment proposer des simplifications et évolutions du cadre réglementaire ?
La création de ce cadre réglementaire visait en particulier les opérateurs de plateforme de vente ou location entre particuliers. Le covoiturage n’était pas la cible évidente mais se retrouve dans ces opérateurs de plateforme. A priori, le raisonnement était que louer un bien ou vendre son véhicule ce n’est pas la même chose. Ainsi cela a amené à la création de deux critères : un premier financier, un second sur le nombre de transactions. Nous en conviendrons, il y a une mesure de tolérance sur l’économie du partage. Cependant, nous ne pouvons vous garantir qu’il n’y aura pas de contrôles dans les mois / années à venir. Ainsi nous vous encourageons vivement à mettre en place des procédures pour vous y conformer. Pour rappel les sanctions peuvent vite monter.
Documentation technique
Préambule
Ce document est un aperçu d'un point de vue technique du Registre de preuve de covoiturage. Le focus est mis sur le back-end. Ce document vous aide à comprendre le fonctionnement du service.
La documentation technique complète est accessible sur le lien suivant 📖.
Concepts
L’application est découpée en services de manière fonctionnelle. Chaque service forme un paquet NodeJS indépendant. L'architecture de ces services est présentée ci-après.
Le proxy joue un rôle d’API manager (routes, auth). Il a vocation à moyen terme à disparaître pour être remplacé par un reverse-proxy ou un API manager.
Service certificate : ce service génère et imprime en PDF ou PNG des attestations de covoiturage des usagers. Par l’intermédiaire de son opérateur, l’usager peut demander un état des lieux de ses trajets de covoiturage sur une période à un instant T. Ce document est produit pour une identité et un opérateur seulement.
Service acquisition : ce service réalise des actions de contrôle de conformité du payload. La conformité du payload est jugée vis-à-vis du format du schéma de données mais également vis-à-vis de règles de bon sens (exemple : date de fin supérieure à date de début). Si le payload est conforme il est envoyé et enregistré en tant que journey dans le service normalization. Un retour est effectué par le service auprès de l’opérateur de covoiturage.
Nous conseillons aux opérateurs de sauvegarder les informations renvoyées par notre API dans un log.
Service normalization : ce service enrichie le journey avec diverses informations comme des codes postaux, des distances théoriques (serveur OSRM), la(les) commune(s) de départ et/ou arrivée, la(les) AOM concernée(s), la densité de population du territoire, etc.
Service acquisition_error : ce service stocke les payloads non conformes aux schémas de données et rejetés par les services acquisition et normalization.
Service carpool : ce service redecoupe le journey (couple passager/conducteur) en un passager et un conducteur et affecte une clef de reconstitution.
Service fraud : ce service réalise des tests d’anomalies sur les données remontées (exemple : nombre de sièges réservés égal à 6, distance 2 km pour une durée de 2H00, etc.) et affecte une note.
Service policy : ce service affecte une incitation aux passagers, conducteurs des trajets éligibles à une campagne d’incitation définie dans le registre.
Service trip : ce service reconstitue le couple passager/conducteur en un journey.
Responsabilité et gestion de la fraude
Ce sont les opérateurs qui sont responsables de la détection, du traitement de la fraude et de la sanction du fraudeur.
Le fait pour un opérateur de créditer un client automatiquement ou rapidement est un choix commercial ou stratégique, il est donc responsable de sa politique interne de versement, c'est donc à lui de supporter le coût de la fraude. L’opérateur peut néanmoins prendre toutes dispositions utiles lui permettant la répétition de l’indu auprès de son client.
L’opérateur s’engage également à traiter les notifications adressées par le RPC dans le cadre de son action d’accompagnement à la détection de trajets suspicieux, à ce titre une procédure à été définie comme suit :
le RPC envoi une communication à l’opérateur en décrivant les comportements suspects identifiés
l’opérateur a 7jrs pour répondre au RPC, confirmer ou non la suspicion de fraude, décrire les actions correctives en cours ou à venir
le RPC fera jouer son devoir de transparence vis à vis de l’AOM et lui communiquera le cas en question :
si la réponse apportée par l’opérateur n’est pas satisfaisante
si la fraude en question est massive ou dure depuis plusieurs mois
ou si les cas de fraudes concernent toujours le même opérateur
A noter que le RPC laissera à l’opérateur la primeur de la communication auprès de l’AOM.
Dernière mise à jour
