PV réception GENERIC

--- tags : generic , pv , maintenance title : PV réception GENERIC robots : noindex , nofollow --- # PV de réception en maintenance de l'application Generic - V0 [TOC] ## Organisation du passage en maintenance Développée essentiellement au SNDIP, l'application Generic est arrivée officiellement en maintenance au SNDIL à partir du premier septembre 2020. Cet atterrissage en maintenance a été précédé d'une phase de transition de mai à septembre 2020, qui a permis à l'équipe de maintenance de monter en compétence dans la connaissance de l'application grâce à l'équipe projet. De nombreuses séances de "passage de témoin" ont permis à l'équipe projet, tant côté métier, qu'informatique, de présenter l'état de l'application et de préciser une bonne partie du fonctionnement fin de celle ci. Il a par ailleurs été convenu que jusqu'à la fin 2020 du temps serait provisionné côté informatique dans le domaine DESSIN (à hauteur de xxx jours) pour venir en aide si besoin à l'équipe de maintenance. Toutes ces dispositions permettent au premier septembre à l'équipe de maintenance de prendre dans de bonnes conditions la maintenance de Generic. L'équipe de maintenance dispose maintenant une vision suffisamment claire lui permettant de pointer des points de vigilance et des axes d'amélioration qui devront être pris en compte pour stabiliser l'application et lui assurer une maintenabilité optimale sur le long terme. La suite de cette note vise donc à faire l'état des lieux de l'application telle qu'elle a été livrée au SNDIL et détailler les différents sujets sur lesquels une attention particulière devra être portée. ## Périmètre fonctionnel couvert par l'application L'application livrée au SNDIL au premier septembre permet de couvrir un périmètre fonctionnel précisé *infra*. Ce périmètre est décrit en comparaison de la définition du projet lors du lancement de celui-ci après la validation de l'étude préalable par le comité des investissement. Généric comporte des blocs de fonctionnalités regroupés en une sous application "Généric_conception" et des blocs de fonctionnalités regroupés en une sous application "Généric_reprise". La mise au point de Généric_reprise a été priorisée de façon absolue à partir de l'automne 2019 ("MVP" ajusté à cette date, réalisé au 15/03/2020). Toutefois, il a été possible d'avancer sur Généric_conception également. L'ensemble livré le 31/08 est proche du "MVP" défini en avril 2019; avec les adaptations "de bon sens", notamment prise en compte de remarques utilisateurs, réalisées. Généric_reprise : Bloc "Collecte", soit les contacts avec les unités, envois des questionnaires, recueil des données (données d'une unité = « dossier »).Ce bloc est fait. Toutefois, il reste à évaluer le besoin et le satisfaire si opportun pour l'intégration de "dossiers" hors Coltrane. Ce besoin apparait notamment pour OFATS. Bloc "Données de gestion / données générales", soit l'affichage et la gestion des données. Essentiellement fait (donc améliorable et à compléter si besoins) Bloc "Courriers et contentieux" soit les fonctionnalités pour les contacts de masse et les contacts spécifiques, notamment le contentieux. La partie "courrier de masse (ouverture, relance, mise en demeure, constat de non réponse, + les courriers individuels disponible *via* Coltrane) est faite. En revanche, les courriers relatifs au contentieux ne sont pas traités. Il faudra réévaluer les besoins métier sur ce point. Bloc "contrôles et gestion des états" : ce bloc est fait (mais améliorable). Il est crucial pour l'expertise des dossiers et a donc été fortement priorisé par l'équipe projet. Cela comprend l'appel du module de contrôle, les calculs et affichages des contrôles et leur criticité, l'impact sur les codes qualité et les changements d'états des dossiers, de façon automatique ou suite à expertise du gestionnaire. Bloc "Généric_suivi", soit les fonctionnalités de comptage et de suivi. Le bloc est fait dans sa définition de base et reprend les fonctionnalités de l'application Généric_suivi (qui fonctionne indépendemment de Généric). Les fonctionnalités permettant des suivis plus spécifiques ou l'affichage de graphiques ne sont pas faites. A noter, sur ce dernier point, que des développements en R basés sur le clone de la base de données ont été faits (séparément) par la MOA de l'ESEM et par ETET. Ces développements sont très intéressants et pourraient être repris. Généric_conception : A noter dans l'IHM (page d'accueil) au 31/08/2020 l'existence d'une "patate" "Généric_administration" et d'une patate "Généric_conception". Suivant cette logique, il a été prévu une patate "Généric_archivage". Il s'agit des accès à différents blocs de fonctionnalité de Généric_conception. Bloc "initialisation", partie faite et gérée par Généric_administration. L"intégration" d'enquête se fait hors Généric, suivant une procédure définie et testée par l'équipe projet. IlL y a un fichier entrant commun à Généric et Coltrane, un "Json est généré" en sortie d'Eno. Les fichiers entrants sont intégrés *via* applishare actuellement. Ce bloc inclut encore les fonctionnalités permettant les modifications d'équipes ou de privilèges, qui ne sont pas faites. Plus en détail, un bloc permettant d'adapter la collecte (modifications de paramètres de contrôles, de données d'quipe, ...) n'est pas fait. L'écran de suivi de batchs devait être développé en binome projet/maintenance, mais cela n'a pu se faire à cause du confinement. Bloc "export et clôture", permettant les exports (fait mais améliorable), la clôture et les fonctionnalités d'archivage (lecture seule des données d'enquêtes précédentes). Ces dernières fonctionnalités ne sont pas faites. ## Carnet d'opérations de l'application Un premier carnet d'opérations a été mis au point conjointement par les équipes projet et les équipes chargées de la maintenance ou de l'administration de l'application Generic. Ce carnet d'opérations permet de définir une priorisation des travaux à réaliser sur l'application. Il contient à la fois des évolutions fonctionnelles qui n'ont pu être prises en compte pendant la phase de projet ainsi que des travaux nécessaires à la stabilisation de l'application et qui doivent permettre d'assurer au mieux de sa maintenabilité. Certains de ces travaux sont issus des points de vigilance soulevés par l'équipe de maintenance de l'application et présentés dans la suite de ce document. Le carnet d'opérations complet est présenté en annexe. [Ajouter le carnet d'opération en annexe] ## Etat du code applicatif Cette partie détaille pour les différents modules de l'application Generic, l'état du code réceptionné et propose un certain nombre de travaux visant conserver une qualité suffisante du code pour assurer sa maintenabilité. ### Front Office développé en Javascript #### Une application javascript satisfaisante L'IHM de l'application Generic est développée en javascript moderne et respecte les recommandations du Cadre de cohérence technique de l'Insee en utilisant notamment les librairies React et Redux. Un audit de code de la partie javascript de l'application réalisé par l'expert Javascript du SNDIL (Nicolas Laval) a permis de s'assurer que la qualité du code javascript est globalement satisfaisante et constitue une bonne base pour les évolutions futures. Un point mérite tout même une attention particulière, il s'agit de l'intégration de la librairie Lunatic. #### Vigilance autour de l'utilisation du composant Lunatic La librairie Lunatic est une bibliothèque javascript de composants graphiques mutualisés développée à l'Insee qui est utilisée pour l'affichage du questionnaire dans Generic. Pour des raisons pratiques et vraisemblablement de manque de temps, une partie de la librairie Lunatic a été réinternalisée en figeant la version et des composants ont été réécrits pour répondre aux besoins exprimés par les premières enquêtes intégrées dans Generic. Ce mode de fonctionnement, s'il a pu donner satisfaction pour les premières enquêtes, devra être revu d'autant plus que la librairie Lunatic va être amenée à évoluer pour proposer de nouvelles fonctionnalités, des corrections de bugs et des optimisations, tout cela en lien avec la filère métadonnées actives (génération des modèles de questionnaire Lunatic grâce à ENO à partir de la description des questionnaires DDI). Il est donc dans l'intérêt de Generic d'être capable de suivre ces évolutions et si possible à moindre coût. Le passage à la V2 de Lunatic a déjà été expertisé avec l'aide de l'expert javascript du SNDIL et montre qu'un certain nombre de modifications seront à apporter pour rendre l'application compatible avec cette nouvelle version. Pour ne pas dégrader l'expérience utilisateur, ces premières adaptations se feront en conservant certains composants spécifiques développés dans le cadre du projet. A terme, il conviendra de se rapprocher le plus possible des composants offerts par Lunatic pour bénéficier au maximum de leur intégration dans la filière des métadonnées actives et limiter les composants spécifiques. Pour cela, il faudra éclaircir en quoi consiste l'"offre de services" Lunatic, sa roadmap et comment les besoins des enquêtes à venir dans Généric pourront être couverts. En tant que composant mutualisé, il pourrait être envisagé que la maintenance Generic contribue au développement dans Lunatic de composants mutualisables et qui lui seraient utiles. ### Back Office développé dans la filière java La partie back-office est composée de 3 modules : core, batch et api, et développée en java 8. Les composants et bibliothèques utilisés sont conformes aux recommandations de la DAAP. #### Etude du code dans Sonar L'utilitaire Sonar, communément utilisé à l'Insee dans la filière java pour mesurer la qualité du code source en continu, permet de dégager certains points d'amélioration. **Indicateurs synthétiques** | Module| Nombre de lignes | Taux de couverture des tests* |Taux de duplication | | -------- | -------- | -------- | -------- | | Core | 5490 | 8% | 10,8%| | Api | 304 | 69% | 1,9%| | Batch | 2156 | 0% | 7,4%| Le taux de couverture de tests (nombre de lignes de code couvertes par des tests) est satisfaisant dans la partie API, elle doit progresser dans la partie Core ainsi que dans les batchs. Le taux de duplication de code reste contenu dans les trois modules. **"Issues" détectées par Sonar synthétiques** Lors de l'analyse automatique du code, une "issue" est créée par Sonar lorsque l'utilitaire détecte qu'une bonne pratique de développement n'est pas respectée. Les issues sont classées selon leur niveau de gravité. Sur le code java de Generic, Sonar fait apparaître plusieurs alertes : 23 bugs, 27 vulnérabilités, 1300 issues simples et 20 jours de dette technique. La majorité des 1300 issues remontées sont des simples défauts de relecture, compréhensibles au regard du calendrier contraint de l'équipe projet : règles de nommage, code mort en commentaires, ... Leur présence n'impacte pas la robustesse de l'application. #### Quelques méthodes complexes à simplifier et rendre plus testables Sonar fournit également un indicateur de complexité cognitive sur le code indiquant sa complexité et de fait les risques liés à une intervention sur celui-ci dans le cadre d'une maintenance. Le point de vigilance pour la maintenance est la présence de 27 méthodes ayant une complexité cognitive supérieur au score de 15, seuil de qualité fixé par l'outil. 11 de ces méthodes ont un score supérieur à 50. Ces méthodes n'ont pas de test, compliquant encore toute intervention. #### La problématique de l'externalisation du module de contrôle Dans un premier temps développé comme un module indépendant, le module de contrôle appelé à la fois par la partie batch de l'application et par l'IHM a été réinternalisé dans le code l'application Generic. Ce choix pourrait, en régime courant, poser des problèmes car il nécessite notamment deux mises en production à chaque modification de contrôles pour une des enquêtes en production. Ce mode de fonctionnement ouvre également la possiblité d'un décalage entre les contrôles du batch et de l'ihm, si cette double mise en production n'est pas réalisée. Ce fonctionnement pose également des problèmes d'organisation. La mise à jour des contrôles, bien que simple, ne peut en pratique être réalisée que manuellement par la RIA. Le déploiement nécessite en effet la maîtrise de 3 éléments très simples : * connaître le procédé technique * connaître la branche ou tag à utiliser * connaître le processus sur les environnements de recette ou de production Cela nécessite une forte coordination de l'équipe et un respect strict du workflow défini pour éviter toute régression. Or, seules RSA et RIA travaillent à temps complet pour Generic. La tâche se retrouve donc systématiquement allouée au RIA. Une solution serait alors d'externaliser le module de contrôles comme un module indépendant comme cela avait été prévu au départ. Cela rendrait alors l'architecture Generic plus modulaire et éviterait les désagréments évoqués plus haut. Le processus de mise à jour de module de contrôle semble également fragile. L'écriture du code, la tenue du dépôt, la mise à jour des outils de développement et le déploiement des livrables sont confiés à des agents hors de la sphère informatique. ### Batchs #### Amélioration de la partie chargement des données **Une sécurisation nécessaire des batchs de chargement des dossiers** Par construction Generic est amené à manipuler de multiples formats : les formats de données Coltrane pour la génération des fichiers de personnalisation, les formats liés à Lunatic pour l'affichage des questionnaires dans l'interface et les formats d'échanges avec le module de contrôles (qui embarque le LSE). Cette complexité nécessiterait autant que possible de s'appuyer sur des schémas XSD lorsque ils sont disponibles ou des routines permettant de s'assurer que les bons formats sont utilisés aux bons endroits. Sur ce sujet, une réflexion est en cours sur un nouveau format de sortie XSD qui serait produit par ENO à partir du DDI, à même de permettre d'être précis dans la gestion des formats des variables des questionnaires lors des phases de chargement d'échantillon et/ou de génération des fichiers de personnalisation. L'intégration d'un tel schéma permettrait d'accroitre la robutesse de la chaine d'intégration des fichiers dans Coltrane en s'appuyant sur les outils de la filière métadonnées. #### Sécurisation de la production des fichiers échantillons L'intégration de la première enquête par l'équipe de maintenance a mis en évidence des faiblesses dans la constitution du fichier échantillon. La complexité du fichier met en difficulté les responsables d'enquête. Un des fichiers a nécessité une vingtaine d'itérations. Ledit fichier a donc été rendu en dernière minute, retardant l'édition du BAT. La collecte aurait pu être compromise par ce retard. >[JFE] une piste d'amélioration ? #### Couverture de tests Aucun test n'a été mis au point sur la partie batch de l'application. Or beaucoup de services sont très complexes. En l'état, il paraît alors improbable de parvenir à déployer une évolution ou un correctif sans causer de régression. Toute modification d'un batch devrait conduire à la rédaction d'un test de bout en bout, nécessitant de : >[JFE] je ne suis pas sûr de comprendre. Il ne faudrait pas plutôt écrire : Toute modification d'un batch devrait conduire au lancement d'un test de bout en bout. L'écriture de celui-ci nécessite de : * générer des fichiers de tests * définir les cas d'utilisation nominal * configurer des tests d'entrée/sortie * développer les tests Cela représente 1 à 3 jours de travail par batch en plus de la configuration initiale (configuration de l'outil cucumber et écriture d'un script pour génération d'une base embarquée). La charge de travail peut s'estimer à environ 15 jours/homme côté informatique, et 2 jours côté statistique. L'écriture de tests unitaires sur le code hérité n'est pas envisagée car trop coûteuse. ### Tests de charge Une opération de test de charge a été menée par le CEI en juin 2020 sur l'application. Les résultats ont donné entière satisfaction. Liste des scénariis testé : TODO // A intégrer ## Base de données Dès le début du projet, une attention particulière a été portée à la base de données de Generic. Une prestation a été réalisée pour optimiser la volumétrie avec le prestataire Cognizant. Avec 4 enquêtes en collecte (Antipol, Esem, CovidT et CovidC), la volumétrie actuelle de la base est de 278 Mo. Dont 217 Mo (80%) uniquement pour les tables partitionnées "valeur" contenant les réponses des entreprises. Ces tables contiennent environ 550000 lignes. De façon très approximative, en multipliant la volumétrie par 45 (15 enquêtes avec 3 ans de données, sans aucune rationalisation du stockage) la volumétrie serait d'environ 10 Go de données. ### Pérennité du modèle de données Suite aux premiers retours des utilisateurs, données enregistrées et problèmes rencontrés, quelques modifications dans le modèle de données paraissent souhaitables. #### Ajouter une table "enquete millesimee" L'ajout d'une table portant l'information sur l'enquête millésimée et facilitera le lien entre l'objet enquête et les objets questionnaire et dossier, notamment pour distinguer les test RG de la collecte et simplifier le concept pour l'archivage. Cela rapprochera également le modèle de données de Generic de celui de Coltrane. #### Scinder la table "dossier" La table dossier contient actuellement 63 attributs. Elle mélange des informations issues du fichier échantillon (identification de l'entreprise, taille, poids, ...) et des informations de suivi de collecte (date d'envoi des courriers et mails, date de réception, code suivi, ...). Il paraît intéressant de scinder cette table pour mieux distinguer les élements relevant de : * l'identification de l'entreprise, potentiellement commun à plusieurs enquêtes et pouvant être conservés pour le prochain millésime * les données d'échantillonnage (poids dans l'échantillon, taille, ...) * les échanges (courriers, mail) * les informations de collecte (code suivi, date de suivi, date d'expertise, ...) #### Optimiser le stockage dans la table valeur Actuellement, la taille de la table "valeur", contenant toutes les réponses des unitées enquêtées, est fixée à l'initialisation de l'enquête. Hors identifiants, cette table a 8 attributs, permettant de distinguer les données collectées, éditées, précédentes, ... pour chaque variable. Un rapide balayage de la table valeur pour l'enquête Antipol, en fin de collecte, a permis d'évaluer plus concrètement le stockage des données : * la table a une taille de 187 Mo, pour un échantillon d'environ 12.000 unités enquêtées et 280 variables * la table a 730.000 lignes, ce qui représente 5.840.000 champs (hors clés) * 4 millions de champs sont vides * Chaque réponse a autant d'espace pré-réservée, quelle que soit sa taille (un boolean réserve autant de place qu'un commentaire) * Chaque unité enquêtée a une ligne pour le code activité et une ligne pour le libellé de ce même code. Les tables "valeur" représentent 80% de la volumétrie de la base. Quelques optimisations permettraient de réduire significativement sa taille en prévision de l'arrivée des futures enquêtes et pérenniserait le fonctionnement de l'application. Ces observations sont à soumettre à Cognizant pour évaluer s'il y a possibilité d'optimisation. #### Question du partitionnement Le partitionnement est la solution envisagée par la prestation de service de Cognizant pour pallier aux problèmes de performance anticipée en début de projet. La surcharge en terme de développement et maintenance du partitionnement semble conséquente. La création des 15 tables partitionnées est faite par des procédures stockées, sur dérogation de la DAAP. > [JFE] Quésako ? Quelle difficulté ça pose ? ## Etat de la documentation La documentation mise à disposition de l'équipe de maintenance tant par les équipes métiers que par l'équipe de projet informatique répond aux attentes exprimées lors de la phase de passage témoin et devrait donc suffire à l'équipe de maintenance qui pourra l'enrichir au fur et à mesure de sa montée en compétence sur l'application. ## Organisation du travail Les premières intégrations d'enquêtes ont montré une tension sur les moyens notamment du côté statistiques, particulièrement au sujet des tâches de coordination des travaux liés à l'intégration correcte des enquêtes dans Generic. Les circuits d'utilisation induits par le fonctionnement de Generic ne favorisent pas l'autonomie des utilisateurs sur des tâches qui relèvent de leur coeur de métier (contrôle de la validité des fichiers d'enquête, gestion des utilisateurs, ...). Les sollicitations récurrentes des utilisateurs par absence d'outillage sont d'autant plus chronophages que le nombre d'enquêtes est croissante, et perturbent fortement le travail de l'équipe de maintenance. Ce manque de moyen est un risque identifié qui peut poser problème en mettant en première ligne la maintenance informatique. ## Conclusion Les quelques points de vigilance mis en avant dans cette note ne sauraient occulter la qualité globale de l'application récupérée en maintenance au SNDIL. Sont à remercier pour cela, l'ensemble des acteurs ayant participé de près ou de loin à la construction de cette application. On soulignera encore une fois l'investissement très appréciable de l'équipe projet dans son ensemble (métier et informatique) pour permettre aux mainteniciens de s'approprier au mieux le fonctionnement de Generic. Partant de cette base solide, il semble cependant utile de garder à l'esprit que pour assurer le programme ambitieux d'intégration enquêtes dans Generic quelques ajustements seront nécessaires. Ces ajustements, détaillés dans cette note, seront en mesure de minimiser les risques et rendre aux utilisateurs le service attendu dans des conditions d'organisation et de travail satisfaisantes pour tous.