# Déroulement des opérations du jour de la mise en prod du lot1



> [Patrick] et update des demandes

L'idéal serait que l'Inpi limite ses envois le matin du jour J à quelques demandes en attendant notre feu vert.
Sauf que pour toutes les indispos, ils disent ne pas pouvoir couper : est-ce qu'on met un rate-limit le temps de valider chez nous (au moins la 1ère heure), est-ce qu'on débute plus tôt (en se référent à la volumétrie quotidienne).

Les livrables doivent être finalisés 2 semaines avant (avant les vacances de la Toussaint), sauf mini-évol non impactante (sinon NoGo)

## Modifier le routage des demandes
* maj applicative (majiba compatible pour avoir la main en dernier recours), a priori seulement des properties qui activent l'aiguillage des déclarations vers Sirene4 pour les créations d'ul
* on a demandé un intégrateur + le Riap à dispo
* toute l'infra et les livrables stables déployés avant
* vérification des flux avant via le Riap, les fonctionnalités de consultation de l'ihm, les api et rundeck

### Est-e qu'on met à jour S3 directement ?
ou est-ce qu'on attend la validation a minima des 1ers traitements S4
* maj applicative possible aussi pour activer la mise à jour côté S3 au dernier moment(sur leur tomcat à l'écoute du broker)/ou déjà déployée avant : Sirene3 valide que c'est possible techniquement par modification de properties également
* :warning: si on ne limite pas les flux on a un risque que les liasses s'accumulent sur le broker le temps de la validation.

### Equipes Sirene 4
1 - Routage des demandes de création UL vers Sirene 4 et arrêt des envois à Sirene 3 pour cette population
#### Validation
* via la base de données : demander rafraîchissement du clone à la demande via si@moi (vérifier la faisabilité avec le RIAP)
* via l'api déclaration interne et l'api de gestion
* via l'ihm admin du broker
* via l'IHM S4, menu de consultation des demandes
* qu'on a bien reçu les demandes
> [Nathalie] a priori on ne peut pas voir les demandes traitées en automatique par l'IHM : dans la version actuelle, il y a soit les demandes à reprendre soit un accès unitaire aux demandes par Siren ou ID, je ne vois pas la possibilité de voir les demandes traitées en automatique)
* via l'IHM S3 qu'ils n'ont pas reçu les demandes (si c'est le scénario retenu)

*Question : bloque-t-on les retours vers le GUE tant que l'on a pas tout vérifié ou laisse-t-on les retours se faire au fil de l'eau ?*
> [Patrick] a priori pas possible (à moindre coût) d'isoler chaque étape du workflow par des majs applicatives en cours de journée. Si on bloque applicativement le workflow, "en l'état" le traitement est terminé avant la maj S3 ou la notif GU selon ce que l'on veut débrancher.
> on peut bloquer la majS3 sur les accès au broker (ils sont d'accord sur le principeà discuter avec S3)
> [Vincent] est-ce qu'on peut bloquer, côté S4, la fin du workflow, après maj et retour S3, avant notifs/maj de demandes ?

2 - Traitements
2.1 Demandes traitées en automatique
#### Validation
* Vérifier le déroulement du workflow via l'API : a-t-il été jusqu'au bout ?
* Vérifier les données inscrites au répertoire (?)
* Vérifier le traitement des données par Sirene 3 (traitent-t-il en direct ou devra-t-on attendre un batch ?)
* Quand le flux retour vers le GUE sera ouvert, verifier qu'ils ont bien eu le retour et qu'il est correct
2.2 Demandes en reprise manuelle
* L'équipe de projet ou un gestionnaire déjà formé traite quelques demandes via l'IHM
* faire les mêmes vérifications que pour les demandes traitées en automatique.

* go/no go à l'issue de cette étape
* Si go :
* Demander à l'Inpi de rouvrir leur flux (en théorie ils ne peuvent pas le couper, il va falloir être plus subtil)
* Prévenir RIAS pour son propre go/nogo
* maj applicative éventuelle pour notification (majiba)
* Si no go :
* Je ne sais pas, c'est un peu la cata :-)
> [Patrick] pour moi, ça dépend du no go, faut qu'on définisse les critères. J'imagine qu'un no go c'est un dysfonctionnement (applicatif ou technique) qu'on ne peut pas réparer dans la 1/2 journée (on peut faire une correction, redémmarrer une base et demander de rajouter des flux). Du coup un no go, tu rebascules tout sur S3 par une maj applicative (qu'on doit avoir sous le coude). Et il faut prévoir un process qui met à jour les données et rebascule les liasses qu'on a commencé à traiter dans S3.
Mais il faut s'en rendre compte avant de notifier, sinon c'est encore plus complexe
### RIAS
* tests sur la maj du répertoire + vérif des fonctionnalités
* puis ouvrir aux sites pilotes

> [Patrick] Pour moi on a un go S4 et un go S3, puis un Go commun (avant de notifier...si possible techniquement)
> il faut qu'on se mette d'accord sur les risques et leur criticité (on peut aussi accepter les risques) : pb d'infra/d'une vm, flux réseau, divergence preprod/prod d'une vm, erreur de version de livrable, trou dans la raquette des tests, absence d'une personne (ou plusieurs), etc.

> [Nathalie] pour le fonctionnement après l'ouverture : le GUE sera-t-il en capacité de nous notifier la validation ou non des siren ? Serons-nous capable de traiter cette notification ? Si le GUE et/ou nous ne sommes pas prêts qu'advient-il du statut du siren (resteront-ils en cours de validation, laissera-t-on la variable vide ?).

## Les Go/NoGo
* "comitologie" : qui participe ?
* on peut faire un Kanban avec liste des tâches assignées à l'ensemble de l'équipe, un label par étape (prérequis, traitement auto, )
* retour sur le planning, des go/no go régulièrement jusqu'à la veille
* le jour J ça ferait un Go S4 pour la fin du traitement, un Go S3 pour la maj (oracle + identification), un Go S4 pour la notif au GU et un Go final commun (apéro ?)

## Le jour J, mais quel jour ?
* pas un week-end, pas un lundi ni un vendredi
* un mardi matin ? analyser les plages "calmes" de réception des liasses les autres jours
* mercredi à éviter ?