---
title: "Connecteur N2F — clients du CRM"
module: integrations
type: functional
status: draft
updated: 2026-09-30
---

# Connecteur N2F — clients du CRM

> Doc fonctionnelle : décrit le **quoi** et le **pourquoi**.

## À quoi ça sert

Aujourd'hui, un client est saisi **deux fois** : dans le CRM Isi-APP, puis à la main dans **N2F**,
le logiciel de notes de frais du groupe, pour qu'un collaborateur puisse imputer une dépense
refacturable.

Ce connecteur supprime la double saisie : **le CRM devient la source unique**. Les clients actifs
y sont poussés automatiquement dans N2F, et s'y maintiennent seuls.

> L'écran de test de l'API — `/admin/n2f` — est un outil d'observation distinct, décrit dans
> [`n2f-expense-api.md`](n2f-expense-api.md). Le présent document porte le connecteur lui-même.

## Quels clients partent dans N2F

Ceux qui portent le statut **Client** sur l'entité ISI concernée — c'est-à-dire, selon la règle
déjà appliquée par le CRM : **une affaire gagnée, signée et non échue**, *ou* **une facture de
moins de 12 mois**.

Au 15 septembre 2026, cela représente **172 clients** sur les trois entités du groupe. Le
connecteur ne redéfinit rien : il reprend le statut que le CRM calcule déjà, visible sur chaque
fiche client.

Un client suivi par deux entités (ISI-APP *et* ISI-DSI, par exemple) part dans les deux sociétés
N2F correspondantes. C'est voulu : les dépenses y sont imputées séparément.

## Comment c'est organisé

**Une instance du connecteur par société N2F**, chacune rattachée à une entité ISI. Le groupe en
compte trois, donc trois instances à terme. Chaque instance dit :

| Réglage | Ce qu'il décide |
|---------|-----------------|
| Plateforme | Préproduction (bac à sable) ou production |
| Société N2F | Où atterrissent les clients |
| Entité ISI source | Quels clients partent |

La **préproduction est le réglage par défaut** : une instance dont la configuration n'est pas
terminée ne peut pas écrire par mégarde dans le référentiel réel du groupe.

## Où ça se passe

Store → **Mes connecteurs** → l'instance N2F. L'écran comporte un panneau **Diagnostic N2F** avec
deux boutons, et la configuration juste en dessous.

### Mettre en route une instance

1. Renseigner le **Client ID** et le **Client Secret** fournis par n2jSoft, choisir la plateforme,
   **enregistrer**. La société n'est pas encore demandée à ce stade — c'est normal, elle s'obtient
   à l'étape suivante.
2. Cliquer sur **Charger les sociétés** : le tableau affiche les sociétés visibles par ces
   identifiants, avec leur identifiant technique.
3. Reporter l'identifiant voulu dans **Société N2F**, choisir l'**entité ISI source**, enregistrer.
4. **Activer l'instance** — c'est seulement à ce moment que société et entité deviennent
   obligatoires.

Le bouton **Tester la connexion** vérifie à tout moment que les identifiants sont acceptés.

## Pourquoi si peu de boutons

N2F **bloque l'accès à son API pendant 12 heures** au moindre dépassement de quota, sans
possibilité d'annulation, et ce blocage vaut pour tout le groupe. Les écrans sont donc conçus pour
que rien ne parte par accident :

- chaque bouton de diagnostic ne déclenche **qu'un seul appel** ;
- deux appels trop rapprochés sur la même instance sont refusés, avec un message ;
- le panneau de test générique du Store est masqué pour ce connecteur : il n'aurait pas su le
  tester, et son bouton n'est pas réservé aux développeurs ;
- l'envoi des clients se fera par **lots bornés** (1, 5 ou 25), jamais les 172 d'un coup.

## Le rythme : la nuit, pas la seconde

N2F interdit les traitements par lot entre **6 h et 21 h**. La synchronisation tournera donc la
nuit : une modification faite dans le CRM est répercutée **la nuit suivante**, pas immédiatement.
Avec environ cinq nouveaux clients par mois, l'écart est invisible à l'usage.

## Retirer un client sans casser l'historique

Un client qui sort du périmètre n'est **jamais supprimé** de N2F : il reçoit une date de fin de
validité. Il disparaît des choix de saisie, mais les notes de frais qui le mentionnent restent
intactes.

## Accès

| Qui | Ce qu'il peut faire |
|-----|---------------------|
| Développeur ISI | Tout : installer, configurer, diagnostiquer |
| Administrateur Store du client | Voit l'instance, ne peut ni la configurer ni la tester |
| Client sans module CRM | Le connecteur n'apparaît pas à son catalogue |
| Session d'assistance | Refusée, même si l'assistant connecté est développeur |

Ce cloisonnement tient à la nature des identifiants : ils sont **globaux à la société N2F**, non
cloisonnés par entité, et le connecteur **écrit** dans le référentiel de notes de frais du groupe.

## Vérifier avant d'envoyer

L'écran **Clients à exporter vers N2F** compare le CRM et N2F **sans rien écrire**, et affiche
quatre compteurs :

| Compteur | Ce qu'il veut dire |
|----------|--------------------|
| À créer | Le client n'existe pas encore dans N2F |
| À mettre à jour | Il existe, mais son nom ou son adresse a changé côté CRM |
| Déjà à jour | Rien à faire |
| Hors CRM | Valeurs saisies à la main dans N2F. **Le connecteur n'y touche jamais** |

L'aperçu n'est **pas chargé automatiquement** : ouvrir ou recharger la page ne consomme aucun appel.

Ensuite, le bouton **Envoyer le lot** pousse **1, 5 ou 25 clients**, jamais les 173 d'un coup. Les
envois sont séquentiels et espacés de quelques secondes : un lot prend donc un petit moment, c'est
normal et c'est ce qui protège l'accès API du groupe.

Deux situations où le bouton reste **volontairement inactif** :

- **la lecture de la liste N2F est incomplète** — des clients paraîtraient « à créer » alors qu'ils
  existent déjà, et l'envoi les écraserait ;
- **les écritures sont verrouillées** sur la plateforme visée (cas de la production tant qu'elle
  n'est pas explicitement ouverte).

## Retirer un client, sans casser l'historique

Un client qui n'est plus « Client » sur l'entité source est **désactivé** dans N2F : il reçoit une
date de fin de validité. Il disparaît des choix de saisie, mais les notes de frais qui le
mentionnent restent intactes. Rien n'est jamais supprimé.

Ces clients apparaissent dans l'aperçu sous l'étiquette **À désactiver**, avant d'être traités.

### Un garde-fou contre le retrait de masse

La synchronisation nocturne tourne sans personne pour la valider. Si une erreur de configuration —
une entité source changée par mégarde, une société N2F repointée — faisait paraître le portefeuille
vide, elle désactiverait tous les clients en une nuit.

Le connecteur **refuse de continuer** dans ce cas : si le CRM ne remonte aucun client actif, ou si
plus d'un dixième des clients devraient être retirés d'un coup, la synchronisation s'arrête et
l'explique dans son journal. Le retrait reste alors possible depuis l'écran, une fois la
configuration vérifiée.

## Quand la synchronisation tourne

Chaque nuit, **entre 21 h et 6 h** : N2F interdit les traitements par lot en journée. Une
modification faite dans le CRM est donc répercutée la nuit suivante.

Pour activer la synchronisation automatique, réglez l'instance sur *Planifié* avec la fréquence
voulue dans l'onglet **Automatisation**. L'ordonnanceur attend l'ouverture de la fenêtre : inutile
de viser une heure précise.

En journée, l'envoi manuel reste possible **jusqu'à 5 clients** — de quoi vérifier un cas
particulier sans attendre la nuit.

### Une société N2F par instance

Deux instances actives pointant la **même** société se désactiveraient mutuellement chaque nuit :
chacune considérerait les clients de l'autre comme sortis de son périmètre. L'application refuse
cette configuration à l'activation.

C'est un piège réel en recette : la préproduction n'expose qu'une seule société. La production,
elle, en expose deux : ISI DSI et ISI APP.

## Ce qui reste à trancher

- **L'adresse est-elle exigée** par N2F ? Sur les 173 clients actifs, **16 n'en ont aucune** en
  base. Ils partent quand même, avec une adresse vide : un client absent de N2F empêcherait
  d'imputer une dépense, une adresse manquante non.
- **Les entités du groupe** (ISI-GROUPE, ISI-DSI) sont elles-mêmes des fiches client dans le CRM :
  elles partiront donc comme clients N2F. Est-ce le comportement voulu ?
- **Le choix du client sera-t-il obligatoire** sur une ligne de dépense refacturable ?
- **Les missions** doivent-elles partir sur l'axe `projects` dans un second temps ?

## Refacturable : le client n'impose rien

Choisir un client sur une dépense **ne la bascule pas** automatiquement en refacturable. C'est un
choix : une réunion interne chez un client, une avant-vente, un déplacement commercial ne se
refacturent pas. L'axe sert à **imputer** la dépense au bon client ; le collaborateur décide
ensuite si elle lui est refacturée.

*(Techniquement, N2F permettrait de forcer ce comportement. Ce n'est volontairement pas activé.)*

## Bon à savoir

**Le CRM a le dernier mot.** Un client désactivé à la main dans N2F sera réactivé à la prochaine
synchronisation, puisque le CRM est la source unique. Pour le retirer durablement, il faut qu'il
sorte du périmètre côté CRM.

**Les entités du groupe ne partent pas.** ISI-GROUPE, ISI-APP et ISI-DSI ont chacune leur fiche
client dans le CRM ; les pousser reviendrait à proposer « ISI-DSI » comme client sur une note de
frais d'ISI-DSI. Elles sont écartées automatiquement, sans liste à tenir à jour.

**Une entité sans client actif donne un écran vide.** C'est le cas d'ISI-GROUPE aujourd'hui : les
clients sont portés par ISI-APP (143) et ISI-DSI (93).

## Voir aussi

- Doc technique : [`.claude/technical-docs/integrations/n2f-crm-connector.md`](../../.claude/technical-docs/integrations/n2f-crm-connector.md)
- Écran de test de l'API : [`n2f-expense-api.md`](n2f-expense-api.md)