DGFiP : adresse IP publique de connexion et adresse postale du contact technique

[jbfeldis]

dpp-72-demo.mp4

Pourquoi

La DGFiP a besoin de deux informations qu'elle ne collecte pas aujourd'hui dans DataPass :
l'adresse IP publique par laquelle le téléservice interroge ses APIs — indispensable à
l'ouverture des accès sur leur APIM — et l'adresse postale professionnelle du contact
technique, pour leurs correspondances.

Retour DGFiP du 11/09, acté le 14/09 : les deux champs sont obligatoires, sur 5 APIs en priorité, les autres « au fil de
l'eau ». L'autocomplétion d'adresse reste hors sujet à ce stade — saisie libre, avec l'annotation qu'ils ont rédigée.

Périmètre

5 APIs, soit 12 classes (bac à sable + production) : SFiP, Impôt Particulier, RIAL,
INFINOE, FICOBA.

SFiP R2P est inclus en plus et reste à faire confirmer par la DGFiP : ils n'ont listé que
« API Courtier fonctionnel SFiP », mais SFiP R2P porte la même marque et récupère le flux des
demandes R2P dépréciées. Si la réponse est non, il suffit de retirer les deux include de
APISFiPR2P et APISFiPR2PSandbox.

Où atterrissent les champs

volumetrie_approximative est rendu dans le bloc basic_infos, pas dans le bloc volumetrie.
Or basic_infos est une étape du formulaire bac à sable et un static_block en production.
« Juste après la volumétrie approximative » (maquette DGFiP) et « sur le BAS » (Natalia) désignent
donc le même endroit.

BAC À SABLE   basic_infos → legal → modalities → scopes → personal_data → contacts
                └─ ADRESSE IP PUBLIQUE                        └─ ADRESSE + COMPLÉMENT

PRODUCTION    static_blocks : basic_infos … contacts   ← hérités, jamais redemandés
              étapes        : operational_acceptance → safety_certification → volumetrie

Ce que ça change pour le stock (annoncé à la DGFiP, vérifié en transaction annulée)

Cas	Effet
Nouvelle demande	Champ obligatoire classique
En cours d'instruction	Rien ne casse, l'instructeur peut toujours valider ; l'habilitation est créée champ vide
Renvoyée pour modification	Re-soumission refusée tant que le champ est vide
Habilitation validée	Aucun impact, jamais revalidée
Mise à jour (réouverture)	Soumission refusée tant que le champ est vide — c'est là que le stock se complétera
Refusée / révoquée / archivée	Aucun impact

Validation de l'adresse IP

IPAddr (stdlib) accepte IPv4, IPv6 et les plages CIDR, et permet de refuser ce qui n'est pas
public : 10.x, 172.16-31.x, 192.168.x, fd00::/8, loopback, lien local, ainsi que
0.0.0.0/0 et ::/0 qui videraient le champ de son sens. Plusieurs adresses séparées par
virgule, point-virgule ou saut de ligne sont acceptées — plusieurs IP de sortie est un cas courant.

Comment tester

En local, /local-sign-in?email=user@yopmail.com puis
/formulaires/api-ficoba-sandbox/demande/nouveau :

1. Étape « Mon projet » — le champ « Adresse IP publique de connexion » apparaît juste après la
   volumétrie approximative, avec le texte d'aide de la DGFiP.
   • vide → bloqué (le champ reçoit required, le navigateur bloque avant l'envoi) ;
   • 192.168.1.10 → refusé côté serveur, message explicite ;
   • 185.24.184.0/24 ou 192.0.2.10 → accepté ;
   • 192.0.2.10, 198.51.100.4 → accepté aussi.
2. Étape « Les personnes impliquées » — dans la carte Contact technique (au-dessus du
   séparateur « Contact supplémentaire », pas en dessous) : « Adresse du contact technique »
   obligatoire avec l'annotation DGFiP, et « Complément adresse » facultatif.
3. Récapitulatif — les deux valeurs s'affichent, côté demandeur comme côté instruction.
4. Passage en production — une fois le bac à sable validé, démarrer la production : les deux
   champs ne sont pas redemandés et les valeurs sont reprises.
5. Hors périmètre — sur une autre API DGFiP (OPALE par exemple), aucun des deux champs
   n'apparaît.

Points d'attention pour la relecture :

• les vues touchées sont partagées par les 36 définitions DGFiP : le cloisonnement tient
  uniquement aux gardes respond_to? et au fait que seules les 12 classes déclarent les attributs ;
• côté consultation, trois fichiers étaient nécessaires : seules api_impot_particulier et
  api_sfip surchargent le bloc contacts, FICOBA / RIAL / INFINOE retombent sur la vue par défaut ;
• /api/v1/demandes exigera les nouveaux champs à la soumission pour ces 5 APIs : à signaler aux
  éditeurs concernés.

Captures

[linear]

DPP-72

[Isalafont]

Peut être juste rajouter des examples côté vu.

Question on attend quel format d'adresse ? X rue de MMM, code postal et ville ? en plusieurs champs ?

Par exemple :
j'ai pu remplir cela et rien n'a bloqué

[Isalafont]

On attend quoi exactement de ce champs ?
une adresse complète avec code postale et ville inclus ?
en un seul champs ou plusieurs champs ?
Je pose la question mais ce n'est pas clairement defini dans le ticket

Sinon même suggestion qu'au dessus :
rajouter un exemple d'adresse fictive différente de celle du message d'erreur.
(Point Accessibilite)

[jbfeldis]

J'ai rajouté un exemple aussi.
On attend... une adresse postale correcte en résumé. Ils voulaient un autocomplete, on n'a pas la bande passante donc on fait au plus simple 🤷

[Isalafont]

Avec les exemples ça me va 👍🏻

Je me demande quand même si on veut un seul champs pour l'adresse complète ou plusieurs disctinct ? (par exemple : un champ adresse, un code postal, un autre ville)
Est ce que ce ne serait pas un moyen de préparer l'autocomplète par exemple ?

[Isalafont]

Techniquement, il n'y a rien qui bloque.
J'ai juste une question sur le fait d'avoir un champs unique vs 3 par exemple mais en l'état si 1 seul champ est ok pour eux alors go