---
title: Chantier territoire 2020
tags: specs, territoire
---

**Table des matières**

[TOC]

:male-pilot: **Jon**
# Echanges

## Echanges du 22/06/2021

- :question: pourquoi les départements sont ajoutés entre () et non un "joint". Pourquoi dupliquer la donnée ?
- Besoin : avoir une indication du type de territoire (commmune, EPCI,, région)
- Besoin : possibilité de sélectionner des EPCI dans le moteur de campagne (choix exceptions trajets)
-
## Echanges du 17/06/2021

##### Opérateurs ayant utilisé des codes INSEE dans les positions de départ / arrivée

certs=# select oo.name from acquisition.acquisitions aa left join operator.operators oo on aa.operator_id = oo._id where payload->'passenger'->'start'->'insee' is not null or payload->'driver'->'start'->'insee' is not null or payload->'passenger'->'end'->'insee' is not null or payload->'driver'->'end'->'insee' is not null group by oo.name;
    name
-------------
 Ecov
 Karos
 Klaxit
 Mobicoop
 Movici
 OuestGo
 OuiHop
 RoulezMalin

## Echanges du 16/06/2021

Participants: Margot, Nico, Jon, Julien, Ludo

1. Synchronisation actuelle écrase les modifications faites pas utilisateurs.
2. Les codes INSEE représentent la plus petite granularité des territoires

#### Comment mutulaliser la partie synchro des territoires entre l'observatoire et le RPC ?

Territoire défini de manière custom dans RPC : Aggrégat de code INSEE. Par exemple plusieurs départements et/ou communes

Besoin fonctionnel : Anticiper les mises à jour de territoires qui ne sont pas fait tout de suite par les producteurs de données (type CEREMA)

Raison de créer des territoires custom :
- Anticiper les MAJ des territoires (Doivent être ecrasés à la syncrhonisation avec le CEREMA)
- Créer des aggrégats spécifiques pour former une AOM comme le Pole Métropolitain (Exemple: super AOM)

Référentiel territoires coté Observatoire :
1. API GEO, n'a pas de millésime et d'EPCI et n'est pas utilisable tel quel
2. Besoin de compléter avec les données de IGN et INSEE

Problèmes de ce modèle pour RPC:
- API Géo n'a pas de millésime
- API Géo renvoie des points géographiques simplifiés et donc pas assez précis

#### Est-ce qu'on peut réutiliser le référentiel de Ludo dans RPC ?

Référentiel Observatoire :
- Construction du référentiel
- Récupération IGN
- Fusion
- Table de passage Commune, Région, CEREMA (id réseau plutot que SIREN qui peut bouger)

#### Comment gèrer les MAJ avec le producteur de donnée ?
- Table de passage avec tous les millésimes

Divergeance si on souhaite utiliser la même base de code:
- Pas besoin d'avoir le millésime coté RPC. Mais pertinent coté Observatoire

Problème d'ajout des millésimes coté RPC :
- Beaucoup d'impact de modifier le modèle de donnée

Gestion des groupements coté Observatoire :
- Données dans un table unique avec tout et reconstruction avec des vues quand besoin (territoires par régions par exemple)

#### Impacts si réécriture avec une table unique coté RPC ?

Impact sur carpool, trip, policy, faudre ...

#### Comment fait on pour mutualiser la base de code ?

Paquet NPM avec script de synchro qui feed les tables sur un modèle commun de tables
Avoir une idée des divergences d'utilisation de ce script

#### Commment concillier territoire customs créés par anticipation avec la synchro qui l'écraserait ?

Scénario d'exemple
1: territoire avec une commune coté producteur de données
2. territire custom avec 2 communes coté RPC
3. synchro avec territoire avec 1 commune coté producteur de données => ne pas écraser la table custom
4. synchro avec territoire avec 2 communes coté producteur de données => Mettre à jour

## Echanges du 26/05/2021

Participants: Margot, Nico, Jon, Julien

### Proposition d'amélioration de la création/modification d'un territoire
1. Enlever la modification de la zone géographique et check que tout est OK en BDD :arrow_right: [ticket ](https://github.com/betagouv/preuve-covoiturage/issues/1375)
2. Pouvoir définir un parent :arrow_right:

### Autres remarques
* La modification des codes INSEE d'un territoire est indispensable
* Besoin, à termes de synchro, les territoires avec une base officielle ( type CEREMA) même si en retard par rapport à la réalité
* Comment faire la synchro? Comment faire cohabiter les territoires définis de manière "custom" et "officiel" ?
* Utilisation d'un table de passage pour avoir un historique des changements (cf ludo)
* Besoin de différencier fonctionnellement:
* Le territoire juridique (agrégat de code INSEE)
* Le partenaire ou utilisateur de la plateforme
* Séparation du formulaire actuel en 2 parties
* Les 1 % des cas exotiques qui auront besoin d'avoir une délimitation géographique cutom seront fait par un dev dans un premier temps

### Action points
* @nmrgt Faire un point technique avec Ludo pour harmoniser la future synchro entre RPC et l'Observatoire ?
* @Jon Vérifier que tous les cas décrits [ici](https://hackmd.io/d0gCY7S8Qku8bUmXrAataw?both#Partie-fonctionnelle) soient couverts par la proposition
* @Jon Implémenter les 2 propositions d'améliorations création de territoire

## Echanges du 11/05/21

**Constat** : la moitié des Communautés de Commune ont choisi de prendre la compétence mobilité (sinon c'est la région qui a la compétence). Conséquence produit : augmentation du nombre de création de territoires dans les mois à venir. La liste officielle du CEREMA ne sera pas communiquée rapidement.

### Questions à résoudre

- Pas de département associé à l'AOM en front (est-ce le cas en back ?)
- Qu'est-ce qu'un district ? (inch'allah c'est un département)
- A quoi servent les champs activables AOM et partenaires ? En fonction de leur sélection des fonctionnalités changent ? Mettre à jour ce [document ](https://hackmd.io/wnY5WKM9SeS_R1-Af4UavA) et/ou le supprimer.

### Problème : visibilité du territoire
Soucis sur l'affectation des parents et respect de la hierarchie de l'arbre.

:arrow_right: solution (Ludo pilote) table de passage entre les différents niveaux.

### Problème : mise à jour des référentiels geographiques
Des codes INSEE de communes changent chaque année. Certains codes disparaissent (ex. fusion de commune) ou sont modifiés.

:arrow_right: solution (Ludo pilote) suivi des modifications dans le temps du référentiel géo (versioning par année)
- en début d'année : obligés d'anticiper pour construire notre référentiel avant de nous recalquer sur le ref de l'INSEE publié plus tard
- meilleure source : base de données IGN "admin-express". données géo associées aux codes INSEE du mois en cours https://geoservices.ign.fr/documentation/diffusion/index.html
- l'API Géo ne publie pas 'vraiment' les données consolidées en amont de la publication de l'INSEE
- Taf déjà fait sur le repo de l'observatoire

### Problème : prise en compte de la densité du territoire
Voir ticket 1190 https://github.com/betagouv/preuve-covoiturage/issues/1190
:arrow_right: solution 1) carroyage (solution actuelle à mettre à jour) / solution 2) discrétisation au chef-lieu (mairie).

**Action : aujourd'hui on reste sur la solution 1 qui apporte une meilleure information.**

### Idées
- Ajouter l'identifiant unique du CEREMA pour les AOMs ;
- Carte de sélection des territoires (cliquer sur les communes pour former le territoire) --> complexe dans un premier temps

### Tickets associés : voir les [tickets avec le label territoires](https://github.com/betagouv/preuve-covoiturage/issues?q=is%3Aopen+is%3Aissue+label%3ATerritoire).
:warning: ce sont les tickets qui concernent plus ou moins des logiques liées à des territoires. Certains sont à spécifier, dans le sprint backlog ou product backlog.

## Echanges du 02/04/2020

#### Super AOM
- Les supers AOMs ne peuvent pas modifier quoi que ce soit de leurs enfants :+1:
- Les supers AOMs peuvent voir :
- Voir leur sous AOM (et sous enfants)
- Les campagnes [en cours] & [passées] de leur enfants (catégoriser par AOM)

#### Mode gruyère
- Le mode d'usage évoqué par Margot
- La possibilité de directement copier / coller les insee des communes à ajouter et des communes à soustraire (donc par la représentation la plus petite des territoires) :
- quid de la résolution technique évoqué avec @nmrgt : de déduire le(s) plus grand territoire pour ensuite optimiser la résolution des trajets (campagnes / affichage des trajets).
- Les territoires sont reliés entre eux sous forme d'arbre organisé en niveaux (@nmrgt est ce que tu pourrais les mettre)
- L'ordre doit être respectés (un département ne peux pas avoir plusieurs régions).
- mais certains niveaux peuvent ignorés (ex. zappé possibilité d'avoir des commune dans les EPCI ou directement dans un département region)
- Dans les cas spécifique entre d'une super AOM contenant une AOM qui déborde (ex lannion) ou a trou (pas de cas rencontré), il n'est pas possible d'ajouter directement cette AOM dans le territoire mais que les codes INSEE concerné. Ce qui veut dire :
- Que la super AOM ne verra pas les campagnes de l'AOM concerné
- Que la super AOM ne verra pas les trajets de la commune uniquement concerné par le débordement (ex un trajet qui part d'ailleur et qui arrive à Lanion).

### Contour géographique <> territory code

La relation territoire <> code (insee, code postal, ...) est déporté sur table plus flexible et est "abstractisé" dans tous les cas ou la relation avec une entitée externe (relation start_insee / end_insee dans les vue matérialisé trip.list, trip.export).

Dans le cas de la france, le code insee permet l'obtention via l'API des contour geographique. Les contours géographique sont stocké dans la table common.insee (table mis à jour manuellement via l'API datagouv). Dans la première implémentation déterminer le point de départ et d'arrivé d'un trajet se faisait par :
- Code insee > common.insee > territory.territories > Territoire (id)
- Coordoonée geographique > common.insee (contour geo) > territory.territories > Territoire (id)

#### Structuration des contour géographiques

Les territoires sont dans la nouvelle implémentation organisé sous forme d'arbre de donnée.

Dans la nouvelle implémentation les contours géographique sont déterminé au cas par cas, en france via l'API insee de datagouv, lors de la création / édition d'un territoire, l'utilisateur peut soit coller des coordonnées geographiques (champs ouvert geojson > multiGeometry) ou entrer des codes insee. seul les contours des territoires contenant un code insee sont stockés (territoire en boute de branche). Les autres territoire n'ont pas tous des contours mais ceux ci peuvent être déterminer à partir de leur enfants.

La table common.insee disparait, les information densité, population, superficie, contour geo sont déplacé dans territoire. Les relations geo ne sont plus par code insee mais par territory_id (ex. carpool.start_insee > carpool.start_territory_id).

#### Résolution des contour géographique > territoires (+AOM)

Lors de la normalisation des trajets la résolution position géographique se fait en 2 étapes
1 - Trouver les territoires en bout de branches (ville) contenant des contour geographique en globant les coordonée fournis
2 - L'agglomération étant trouvé, on remonte la chaine des territoires contenant cette ville pour en resortir la liste des AOMS concernés

## Echanges du 30/01/2020

### Relations dans la base

Relations de `territory_id` liant un territoire en particulier.

- :white_check_mark: `auth.users` : un utilisateur appartient à un seul territoire
- :white_check_mark: `certificate.certificates` : une attestation est délivrée sur un seul territoire
- :white_check_mark: `policy.policies` : une politique est lancée par un seul territoire
- :warning: `policy.trips` : `start_territory_id` et `end_territory_id` retournent 1 seul territoire par INSEE (voir `territory.insee`)
- :warning: `territory.insee` : `_id (INSEE)` est une _PRIMARY KEY_ donc _UNIQUE_. On ne peut donc pas lier plusieurs territoires à un code INSEE.
- :white_check_mark: `territory.territory_operators` : relation 1-to-1 entre les opérateurs et les territoires. Pour les intersections de territoires, les opérateurs devront se déclarer visibles ou non-visibles pour chacun.
- :warning: `trip.export` : même problème que `policy.trips`
- :warning: `trip.list` : même problème que `policy.trips`
- :white_check_mark: `trip.stat_cache` : une cache pas territoire

#### Proposition Margot :

Par exemple : Trajet Lyon-Villeurbanne :
Départ
* Commune : Lyon
* TerritoireCollTerr = Grand Lyon
* Libre : Pôle Métropolitain
* Département = 69
* Région = AURA
* Etat = France

#### Proposition Nicolas :

Nous avons 3 sorte de données sur les territoires :
- les données géographique (contour, densité, codes postaux, etc)
- les données "entreprises" (siret, naf, adresses, etc)
- ce qui est lié à l'utilisation du registre (cgu, contacts, etc)

L'objectif est que l'on puisse lier un trajet à plusieurs territoires. Cette modification va avoir un gros impact sur la base de données et des impacts relativement important sur les couches métiers.

On doit conserver des données géographiques pour permettre le rattachement d'un trajet - on dispose aujourd'hui des contours des codes insee pour ce faire.

Les données "entreprise" et liés à l'utilisation du registre ne sont pas centrales dans la problématique, les une étant déjà logées dans une table distincte et les autres pouvant être aisément stocké dans un champs JSON car relativement peu importantes.

Je propose donc de :
- fusionner la table "géo" avec la table "territoire". Ainsi, chaque code insee actuel devient "territoire" ;
- permettre à un territoire d'avoir un ou plusieurs territoire "enfants" ;
- permettre à un territoire de ne pas avoir de données géographiques ;
- permettre à un territoire de ne pas avoir de données "entreprise" ou "registre" ;

Ainsi, lors de la normalisation des données, au lieu de rattacher un trajet à un code insee, on le rattache au "territoire" le plus petit (celui qui n'a pas d'enfant). L'avantage de l'approche :
- on est très abstrait (on peut faire une région, un département, ou autre ca change rien) ;
- on garde un point de départ/arrivé par trajet ;
- on couple faiblement les relations aux codes insee (ce qui est blocant pour l'utilisation du code dans d'autres pays) et va permettre (voir plus bas) de faire des recherches plus performante côté interface ;
- vu le système de permission, ce modèle sera relativement facile à adapter ;

Par contre, cela necessitera une adaptation côté front-end de manière à ce que les codes insee ou autre recherche faite par les utilisateurs soit "convertit" en territoire. Ainsi, techniquement, il n'y a pas de recherche de trajet départ insee 0000 vers insee 0001, il y a une recherche d'un trajet de tel territoire vers tel autre, les territoires parents ayant accès à ces données.

## Stratégie

#### Proposition :

- Faire un soft-delete des codes supprimés pour garder la référence pour les anciens trajets qui ont été effectués lors de l'existence de ce code INSEE.
- Modifier les codes modifiés (ex. modification du contour géo, nom de commune...)
- Permissions

## Ressources

- COG : https://www.insee.fr/fr/information/2560452
- COM (outre-mer) : https://www.insee.fr/fr/information/2028040

### Design de db (back)
AVANT :

CREATE TABLE IF NOT EXISTS common.insee
(
  _id varchar primary key,

  town varchar(64),
  country varchar,

  density integer,

  postcodes varchar(10)[],
  geo geography
);

CREATE TABLE IF NOT EXISTS territory.territories
(
  _id serial primary key,
  parent_id integer, -- REFERENCES territory.territories (_id),

  created_at timestamp with time zone NOT NULL DEFAULT NOW(),
  updated_at timestamp with time zone NOT NULL DEFAULT NOW(),
  deleted_at timestamp with time zone,

  siret varchar NOT NULL,
  name varchar NOT NULL,
  shortname varchar,

  cgu_accepted_at timestamp with time zone,
  cgu_accepted_by varchar,

  company json NOT NULL,
  address json NOT NULL,
  contacts json NOT NULL
);

APRÈS :

--- insee, postcode, town, country
CREATE TYPE territory.code AS (
    type varchar(10),
    value varchar(64)
);

CREATE TABLE IF NOT EXISTS territory.territories
(
    _id varchar primary key,
    name varchar,
    shortname varchar,
    children: int[],

    --- geo data
    codes territory.code[],
    density integer,
    geo geography,

    --- if territory has account
    active: boolean,
    active_at: timestamp with time zone,
    company_code: varchar, -- siret
    company_meta: json,

    --- timestamps
    created_at timestamp with time zone NOT NULL DEFAULT NOW(),
    updated_at timestamp with time zone NOT NULL DEFAULT NOW(),
    deleted_at timestamp with time zone
);

Table matérialisée :
- pour la normalisation, on a besoin :
- des territoires les plus petits (ceux sans enfants)

- pour les politiques, on a besoin :
- de la liste des parents sur les territoires les plus petits

- pour trip, on a besoin :
- de la liste des enfants les plus petits pour un territoire
- une table avec les codes des plus petits

- pour les permissions :
- la liste des territoires enfants

- parents
- children
- merger
- codes
- densité
- geo

### Chantiers back
- Territory
- Normalization
- Carpool - MAJ
- Trip/Policy/Fraud - MAJ

### Chantiers front
- CRUD territoire
- Mise en place d'un outils permettant d'ajouter des territoires et supprimer d'autre territoire à partir d'une dénomination (Commune, EPCI, Region, ...) en utilisant la recherche de territoire.
- L'état de l'opération (boolean) n'est pas stocké, seul ce qui en résulte est stocké (voir relation parent / DB), l'utilisateur ne verra au final que les territoires liés.
- ? Resolution des opérations boolean coté backend a savoir que dans l'ideal on devrait résoudre ces opérations de façon à garder des relations au niveau le plus optimal en liant avec le besoin Super AOM > AOM :
- ex 1 : On prend AURA on enlève le Grand Lyon, on devrais y avoir comme résultat les département : Ain + Allier + Ardèche + Cantal + Drôme + Isère + Loire + Haute-Loire + Puy-de-Dôme + Rhône + Savoie + Haute-Savoie et non tous les territoires au plus bas niveau (toutes les communes dans la zone AURA)
- ex 2 : On prend AURA - Clermont Ferrand on devrait avoir comme résultat optimal Ain + Allier + Ardèche + Cantal + Drôme + Isère + Loire + Haute-Loire + Rhône + Savoie + Lyon Metropole + Haute-Savoie + (toute les EPCI / Communes du Puy-de-Dôme - Clermont Ferrand)
- Si l'ex 2 n'est pas cas un cas d'usage envisagable alors il faut restreindre à l'utilisateur a faires des opérations avec des territoires du même niveau (departement dans l'ex 2) et donc :
- Avoir des niveaux prédéfini avec des contraintes à définir niveau métier
- Avoir un champ niveau dans territoire
- L'approche apporte beaucoup de contrainte métier et rendrais plus difficle la création de territoire "battard" type Pôle économique de Lanion + Centre ville de Lanion pour des cas de campagne spécifique rencontrée.

- La solution plus technique serait de laisser cours à la créativité du registre en résolvant les relations de façon algorythmique (en R**T si possible).

- Mise en place d'un relation Super AOM > Sous AOM
- Gestion d'AOM à l'interieur d'AOM
- Ces supers AOMs peuvent elles créer des sous AOMs ou c'est gérer coté utilisateur registre ?. Seul le super admin peut créer des territoires
- ? Collision avec les opérations boolean

- les sociétés sont lié par un id et non un numéro de SIRET (intertionalisation)
- application du nouveau format company:fetch pour la recherche par numéro de siret
- adresses, contacts devrait garder sa structure
- Differentiation de process de création enter les territoires geographique et les AOMS (à savoir qu'une AOM est un territoire avec au moins une adresse et ou des coordoonées sociétés qui a valider les conditions d'utilisation)

- Recherche de territoire
- Recherche par nom
- MAJ des vues Trip
- Application du nouveau format de donnée
- Tenir du compte du faite qu'un trajet peut partir et arrivée de plus territoires different :
- ? Afficher le territoire le plus petit (ou AOM) ou pour les opérateurs
- ? Afficher la commune la plus petite pour les AOM
- ? Quoi afficher pour l'utilisateur registre
- être en mesure de dupliquer le territoire
- adresse manquantes mais obligatoire pour les entreprises @margot a créé un ticket

Nouvelle spécification :
Super AOM peut voir les campagnes en cours sur son territoire (exemple : sous AOM ou région qui peut voir les autres) mais sans possibilité de modifier.

# Partie fonctionnelle

## 1 : l'incitation multiple sur un même trajet
### Contexte réglementaire

Avec la LOM, l’ensemble du territoire est couvert par des Autorités Organisatrices de la Mobilité. Concrètement, la loi laissera le choix aux communes, via leur intercommunalité pour qu’elles s’emparent de la compétence, et à défaut les régions seront compétentes.

Les communautés de communes pourront prendre la compétence mobilité. Le conseil communautaire devra délibérer sur cette prise de compétence au plus tard avant le 31 décembre 2020.
Dans les communautés de communes qui n’auront pas choisi de prendre cette compétence au 1 er janvier 2021, les régions deviendront AOM en subsidiarité, en complément de leur compétence mobilité régionale.

La région AOT devient « AOM régionale » (AOMR) et étend sa compétence à l'ensemble des services de mobilité organisés par les AOM au niveau local.

En conséquence, il devient possible pour un acte de covoiturage d'être incité à la fois par son AOM (CollTerr) et son AOMR. Par exemple : incitation de la part du Grand Lyon ET de la part de la région AURA.

### Besoin 1

Avoir une liste de territoires correspondants à un code INSEE de façon à pouvoir appliquer plusieurs incitations, **faire remonter les trajets sur plusieurs territoires**. Par exemple, un trajet Lyon - Villeurbanne apparait sur le dashboard du Grand-Lyon et celui de la région Rhône-Alpes.

## 2 : une nouvelle AOM non présente dans la liste du CEREMA - SUPER AOM = fusion d'AOM existante
#### Contexte réglementaire et technique
La liste des territoires AOM sur laquelle est basée le service est mise à jour par le CEREMA. La mise à jour est publiée en juillet de chaque année et reprend les nouvelles AOM créées au 1 janvier de l'année (cf : [dernière mise à jour](https://www.cerema.fr/fr/actualites/liste-composition-autorites-organisatrices-mobilite-au-1er-1)).
En conséquence durant le premier semestre de l'année, cette nouvelle AOM n'est pas présente dans notre liste et pourtant du point de vue réglementaire il s'agit bien d'une AOM pouvant accéder à nos services.

Exemple : depuis le 1er janvier 2020, le SMTC de Grenoble, la Communauté de Communes du Pays du Grésivaudan et la Communauté d'Agglomération du Pays Voironnais ont fusionné pour devenir le SMMAG, Syndicat Mixte des Mobilités de l‘aire grenobloise.

### Besoin 2
**Pouvoir créer une SUPER AOM reprenant les anciennes AOM et reprenant les trajets réalisés dans le passé sur les anciens territoires.**

## 3 : une nouvelle AOM non présente dans la liste du CEREMA - SUPER AOM = fusion d'AOM existante + Communauté de Communes
#### Contexte réglementaire et technique
La Loi du 16 décembre 2010, portant sur la réforme des collectivités locales, a institué la création des pôles métropolitains qui permettent l’association d’établissements publics de coopération intercommunale (EPCI) à fiscalité propre. On peut donc avoir des Pôles Métropolitains qui se forment en regroupant des EPCI qui ont pour objectif de devenir AOM mais ont pour l'instant une "délégation de compétence".

Exemple : Le Pôle métropolitain du Genevois Français est un regroupement de :
* Communauté d'agglomération du Pays de Gex : AOM
* Communauté d'agglomération Annemasse Agglo : AOM
* Communauté d'agglomération Thonon Agglomération : AOM
* Communauté de communes du Genevois : AOM
* Communauté de communes du Pays Bellegardien : La ville de Bellegarde est AOM mais pas la CC. Il manque donc une partie du territoire (haché vert)
* Communauté de communes Arve et Salève + Communauté de communes Faucigny-Glières + Communauté de communes Pays Rochois : AOM sous la forme du syndicat Mixte des 4 communs. Mais Onnion n'est pas dans le Pôle Métropolitain (contour Jaune).

Le Pôle aujourd'hui est AOM partielle, pas de compétence Transports en Commun mais une délégation de compétence sur le covoiturage. Au 1 janvier 2021 ceci sera officialisé. En conséquence, on

### Besoin 3
**Pouvoir créer une SUPER AOM reprenant les anciennes AOM des communautés de communes via un outil de sélection de code INSEE**

## 4 : un syndicat Mixte cohabitant avec des AOM.
### Contexte réglementaire et technique
Code des transports - Article L1231-1
Dans leur ressort territorial, les communes, leurs groupements, la métropole de Lyon et les syndicats mixtes de transport sont les autorités compétentes pour organiser la mobilité.
L’article 35 de la Loi Mobilité permet à ces autorités compétentes de verser une allocation aux passagers et conducteurs d’un trajet réalisé en covoiturage. En d’autres termes, un Syndicat Mixte de Transport regroupant plusieurs autres AOM devient lui même une AOM.

Exemple : le SMTCO (Syndicat Mixte des Transports en Commun de l'Oise) c’est
* Le département de l’Oise ⇒ Non AOM
* La région Hauts de France ⇒ AOM
* Le Communauté d’Agglomération du Beauvaisis (CAB) ⇒ AOM
* La Communauté d’Agglomération Creil Sud Oise (ACSO) ⇒ AOM
* La Communauté d’Agglomération de la Région de Compiègne et de la Basse Automne ⇒ AOM
* La Communauté de Communes des Sablons ⇒ AOM
* La commune de Liancourt ⇒ AOM
* La commune de Chantilly ⇒ AOM
* La commune de Pont-Sainte-Maxence ⇒ AOM
* La commune de Noyon ⇒ AOM
* La commune de Crépy en Valois ⇒ AOM
* La commune de Senlis ⇒ AOM
* Le Syndicat Intercommunal des Transports collectifs de l’Agglomération de Clermont ⇒ AOM

Le SMTCO avec une SUPER AOM regroupant l’ensemble du département de l’Oise (y compris les trajets sur des villes-villes non compris sur une AOM à l'origine).
Les AOM en dessous peuvent avoir un sous-compte spécifique à leur territoire.

### Besoin 4
**Pourvoir faire un super compte en indiquant des codes INSEE tout en conservant la possibilité de faire des sous-comptes** pour les AOM comprises dans ce super compte (conserver la maille de l'EPCI)

## 5 : Un Pôle Métropolitain regroupant AOM, CC, départements et à cheval sur plusieurs départements.
Exemple : Pôle Métropolitain de Lyon. Avec le Syndicat Mixte des Transports de l'Aire Métropolitaine Lyonnaise (SMT AML), le Pôle Métropolitain poursuit l'objectif d'améliorer et de rendre plus attractive l'offre de mobilité et de déplacement dans la métropole.

Ce territoire n'a pas de compétence mobilité mais pourrait demander un accès.