Vitam - Contributions [fr]

Accueil

2025-03-26T13:31:57Z

Jmminy : /* QA */

Bienvenue sur le wiki du projet Vitam. Il a pour objectif principal de centraliser la base de connaissance du projet concernant le développement, le devops et le support.

== [[MULTITEAM]] ==
== [[DEVOPS]] ==
== [[SUPPORT]] ==
== [[AGILITÉ]] ==
== [[ONBOARDING]] ==

== [[QA]] ==

== FAQs ==

QA

2025-03-26T13:31:30Z

Jmminy : Page créée avec « === Equipe === Raouaa MEDJOUB Soufyane SERIR Ayoub BEN KHADAJ »

=== Equipe ===

Raouaa MEDJOUB

Soufyane SERIR

Ayoub BEN KHADAJ

Accueil

2025-03-26T13:28:55Z

Jmminy :

DEVOPS

2025-03-26T13:27:57Z

Jmminy :

== Présentation de l'équipe ==

-Achoubie Mohamed

-Amrani Saad

-Bouayad Abderahmane

-Babacar

-Georges Julien

== Upload snapshot spécial odfvalidator sur nexus ==
A défaut d'avoir mieux (upgrade réel & MAJ code), pour injecter la lib dans le nexus :

Récupérer la version odfvalidator depuis un précédent build (dans un RPM ou DEB)<syntaxhighlight lang="bash">
mvn deploy:deploy-file -DgroupId=org.apache.odftoolkit \
-DartifactId=odfvalidator \
-Dversion=1.2.0-incubating-SNAPSHOT \
-Dclassifier=jar-with-dependencies \
-Dpackaging=jar \
-Dfile=/path/to/odfvalidator-jar-with-dependencies.jar \
-DrepositoryId=vitam \
-Durl=https://nexus.dev.programmevitam.fr/repository/maven-snapshots/
</syntaxhighlight>

MULTITEAM

2024-06-11T13:21:57Z

Jmminy : /* Checkmarx */

== Présentation de l'équipe ==

- GHERIBI Lotfi

- RADEAU Daniel

- BERTOUL Raouaa

- SERIR Soufyane

- LEMAIRE Sandrine

- MINY Jean-Marie

- BERNARD Etienne

- TIZAOUI Mohamed

- BENARBIA Benaissa

- PARIS Alexandre

- NAJI Hossame

- ROBERT Maxime

- FATAN Souhaib

- JOSSE Isabelle

- VILLE Marion

- WELLHOFF Leo

[https://osmose.numerique.gouv.fr/jcms/p_2694773/fr/vitam-trombi Trombinoscope]

[https://docs.google.com/spreadsheets/d/12s-rlw3YEukqnjHTh9Kb9FhRfzY2J3hHdP81LBu_oHY/edit?pli=1#gid=0 Tableau de suivi des présences (Global)]

[https://docs.google.com/spreadsheets/d/1PiE6gQ2yFORZNtOYhkFugdmnMbPHhFdfCXapw5E-O6c/edit#gid=0 Planning Qualification Support]

== Procédures ==

[[Création d'une MR / PR]]

[[Review d'une MR / PR]]

[[Procédure d'installation Vitam Core pour développement local v.1.0]]

[[Formatage du code]]

[[VPN et SSH]]

== DOR : Definition Of Ready ==

* Estimation et criticité doivent être définie
* Le besoin et le context de l'US doit être compris par tous et retranscrit dans la description
* Un maximum de 7 critères d'acceptances
* Les maquettes doivent être à jour et terminées avec un lien FIGMA
* Il faut anticiper les scénarios UX
* Les traductions doivent être présentes
* Les US doivent être découpées en tâches
* Un tech design validé
* Identifier les aspects de refontes
* Identifier le travail sur les tests
** Quel niveau pour les TI
** Quel niveau pour les tests end to end ( TNR & Front selenium )
* Fournir des jeux de tests et des exemples
* Les dépendances entre US doivent avoir été identifiées

== DOD : Definition Of Done ==

* DoD Développement
** Tous les critères d'acceptances sont implémentés
** Le Build est valide
** Test nominaux sur INT / BAC à sable / Local
** Alimenter le changelog
** Fournir des jeux de données supplémentaires
** Fournir la requête REST pour les tests d'API
** Review du code OK
* DoD Testing
** TU ( Java et/ou Angular )
** TI
** TNR
** End to End auto
* DoD Documentation
** Compléter le Tech Design
** [[Les RAML]]
** [[Documentation d'architecture (DAT)]]
** [[Documentation d'exploitation|Documentation d'exploitation (DEX)]]
** [[Documentation d'installation|Documentation d'installation (DIN)]]
** [[Documentation de migration|Documentation de migration (DMV)]] ( Script de montée de version ... )
** Le fichier README
** [[Mise à jour de l'ADR ( Log d'architecture )]]
** [[Listing des requêtes HTTP]]
** [[Documentation du workflow]]
** [[Documentation sur le modèle de données]]
* DoD Validation QA&UX
** Validation UX design
** Validation nominale
** Validation INT
** Validation ITREC
* DoD Validation PO
** Vérification documentaire
** Relecture finale

== Outils ==
Cette section recense les outils à disposition et leur usage dans le cadre du projet

== Jenkins ==

[https://jenkins.dev.programmevitam.fr/ Jenkins]

[https://jenkins.dev.programmevitam.fr/jenkins/job/doc-homepage/ws/index.html Tableau de Bord Vitam]

== Gestion des tickets ==

[https://assistance.programmevitam.fr/ Tuleap Bugtracker]

- Artefact USER STORIES est celui du projet

- Artefact DEMANDE PARTENAIRE est à suivre, recopier dans USER STORIES et à répondre aux partenaires

- Artefact Bugs = tickets de Bug de VITAM que notre recetteuse cherche à traiter avec l’Administration et l’équipe de dev.

== Contributions (Git) ==

[https://gitlab.dev.programmevitam.fr/vitam/vitam/merge_requests GitLab Vitam]

[https://github.com/ProgrammeVitam/vitam-ui/pulls Github Vitam UI]

Sert à suivre les états des MR. Une MR a le numéro du ticket Tuleap dans le titre (doit l'avoir en tout cas, sinon tu ne peux pas savoir si OK ou KO )

NB : Les accès sont gérés par les devOps

== Checkmarx ==
[https://checkmarx.preprod.programmevitam.fr/ Checkmarx]

Attention pour s’authentifier, choisir en option le : « VITAM OpenLdap »

Enregistrement de la formation du 5 juin 2024 : https://youtu.be/MbJuksyuu4I
<youtube>MbJuksyuu4I</youtube>

== Sonar ==
[https://sonar.preprod.programmevitam.fr/dashboard?branch=develop&id=fr.gouv.vitam%3Aparent Tableau de bord (Preprod)]

== Squash ==
[https://squashtm.dev.programmevitam.fr/squash/login Tableau de bord Squash (multi projet)]

== Liens utiles ==
[https://www.programmevitam.fr/2023/11/13/vitam-en-ligne-interventions/ Webinaires]

MULTITEAM

2024-06-11T13:21:05Z

Jmminy : /* Checkmarx */

== Présentation de l'équipe ==

- GHERIBI Lotfi

- RADEAU Daniel

- BERTOUL Raouaa

- SERIR Soufyane

- LEMAIRE Sandrine

- MINY Jean-Marie

- BERNARD Etienne

- TIZAOUI Mohamed

- BENARBIA Benaissa

- PARIS Alexandre

- NAJI Hossame

- ROBERT Maxime

- FATAN Souhaib

- JOSSE Isabelle

- VILLE Marion

- WELLHOFF Leo

[https://osmose.numerique.gouv.fr/jcms/p_2694773/fr/vitam-trombi Trombinoscope]

[https://docs.google.com/spreadsheets/d/12s-rlw3YEukqnjHTh9Kb9FhRfzY2J3hHdP81LBu_oHY/edit?pli=1#gid=0 Tableau de suivi des présences (Global)]

[https://docs.google.com/spreadsheets/d/1PiE6gQ2yFORZNtOYhkFugdmnMbPHhFdfCXapw5E-O6c/edit#gid=0 Planning Qualification Support]

== Procédures ==

[[Création d'une MR / PR]]

[[Review d'une MR / PR]]

[[Procédure d'installation Vitam Core pour développement local v.1.0]]

[[Formatage du code]]

[[VPN et SSH]]

== DOR : Definition Of Ready ==

* Estimation et criticité doivent être définie
* Le besoin et le context de l'US doit être compris par tous et retranscrit dans la description
* Un maximum de 7 critères d'acceptances
* Les maquettes doivent être à jour et terminées avec un lien FIGMA
* Il faut anticiper les scénarios UX
* Les traductions doivent être présentes
* Les US doivent être découpées en tâches
* Un tech design validé
* Identifier les aspects de refontes
* Identifier le travail sur les tests
** Quel niveau pour les TI
** Quel niveau pour les tests end to end ( TNR & Front selenium )
* Fournir des jeux de tests et des exemples
* Les dépendances entre US doivent avoir été identifiées

== DOD : Definition Of Done ==

* DoD Développement
** Tous les critères d'acceptances sont implémentés
** Le Build est valide
** Test nominaux sur INT / BAC à sable / Local
** Alimenter le changelog
** Fournir des jeux de données supplémentaires
** Fournir la requête REST pour les tests d'API
** Review du code OK
* DoD Testing
** TU ( Java et/ou Angular )
** TI
** TNR
** End to End auto
* DoD Documentation
** Compléter le Tech Design
** [[Les RAML]]
** [[Documentation d'architecture (DAT)]]
** [[Documentation d'exploitation|Documentation d'exploitation (DEX)]]
** [[Documentation d'installation|Documentation d'installation (DIN)]]
** [[Documentation de migration|Documentation de migration (DMV)]] ( Script de montée de version ... )
** Le fichier README
** [[Mise à jour de l'ADR ( Log d'architecture )]]
** [[Listing des requêtes HTTP]]
** [[Documentation du workflow]]
** [[Documentation sur le modèle de données]]
* DoD Validation QA&UX
** Validation UX design
** Validation nominale
** Validation INT
** Validation ITREC
* DoD Validation PO
** Vérification documentaire
** Relecture finale

== Outils ==
Cette section recense les outils à disposition et leur usage dans le cadre du projet

== Jenkins ==

[https://jenkins.dev.programmevitam.fr/ Jenkins]

[https://jenkins.dev.programmevitam.fr/jenkins/job/doc-homepage/ws/index.html Tableau de Bord Vitam]

== Gestion des tickets ==

[https://assistance.programmevitam.fr/ Tuleap Bugtracker]

- Artefact USER STORIES est celui du projet

- Artefact DEMANDE PARTENAIRE est à suivre, recopier dans USER STORIES et à répondre aux partenaires

- Artefact Bugs = tickets de Bug de VITAM que notre recetteuse cherche à traiter avec l’Administration et l’équipe de dev.

== Contributions (Git) ==

[https://gitlab.dev.programmevitam.fr/vitam/vitam/merge_requests GitLab Vitam]

[https://github.com/ProgrammeVitam/vitam-ui/pulls Github Vitam UI]

Sert à suivre les états des MR. Une MR a le numéro du ticket Tuleap dans le titre (doit l'avoir en tout cas, sinon tu ne peux pas savoir si OK ou KO )

NB : Les accès sont gérés par les devOps

== Checkmarx ==
[https://checkmarx.preprod.programmevitam.fr/ Checkmarx]

Attention pour s’authentifier, choisir en option le : « VITAM OpenLdap »

Enregistrement de la formation du 5 juin 2024 : https://youtu.be/MbJuksyuu4I

<nowiki><youtube>MbJuksyuu4I</youtube></nowiki>

== Sonar ==
[https://sonar.preprod.programmevitam.fr/dashboard?branch=develop&id=fr.gouv.vitam%3Aparent Tableau de bord (Preprod)]

== Squash ==
[https://squashtm.dev.programmevitam.fr/squash/login Tableau de bord Squash (multi projet)]

== Liens utiles ==
[https://www.programmevitam.fr/2023/11/13/vitam-en-ligne-interventions/ Webinaires]

MULTITEAM

2024-06-05T14:20:57Z

Jmminy : /* Procédures */

== Présentation de l'équipe ==

- GHERIBI Lotfi

- RADEAU Daniel

- BERTOUL Raouaa

- SERIR Soufyane

- LEMAIRE Sandrine

- MINY Jean-Marie

- BERNARD Etienne

- TIZAOUI Mohamed

- BENARBIA Benaissa

- PARIS Alexandre

- NAJI Hossame

- ROBERT Maxime

- FATAN Souhaib

- JOSSE Isabelle

- VILLE Marion

- WELLHOFF Leo

[https://osmose.numerique.gouv.fr/jcms/p_2694773/fr/vitam-trombi Trombinoscope]

[https://docs.google.com/spreadsheets/d/12s-rlw3YEukqnjHTh9Kb9FhRfzY2J3hHdP81LBu_oHY/edit?pli=1#gid=0 Tableau de suivi des présences (Global)]

[https://docs.google.com/spreadsheets/d/1PiE6gQ2yFORZNtOYhkFugdmnMbPHhFdfCXapw5E-O6c/edit#gid=0 Planning Qualification Support]

== Procédures ==

[[Création d'une MR / PR]]

[[Review d'une MR / PR]]

[[Procédure d'installation Vitam Core pour développement local v.1.0]]

[[Formatage du code]]

[[VPN et SSH]]

== DOR : Definition Of Ready ==

* Estimation et criticité doivent être définie
* Le besoin et le context de l'US doit être compris par tous et retranscrit dans la description
* Un maximum de 7 critères d'acceptances
* Les maquettes doivent être à jour et terminées avec un lien FIGMA
* Il faut anticiper les scénarios UX
* Les traductions doivent être présentes
* Les US doivent être découpées en tâches
* Un tech design validé
* Identifier les aspects de refontes
* Identifier le travail sur les tests
** Quel niveau pour les TI
** Quel niveau pour les tests end to end ( TNR & Front selenium )
* Fournir des jeux de tests et des exemples
* Les dépendances entre US doivent avoir été identifiées

== DOD : Definition Of Done ==

* DoD Développement
** Tous les critères d'acceptances sont implémentés
** Le Build est valide
** Test nominaux sur INT / BAC à sable / Local
** Alimenter le changelog
** Fournir des jeux de données supplémentaires
** Fournir la requête REST pour les tests d'API
** Review du code OK
* DoD Testing
** TU ( Java et/ou Angular )
** TI
** TNR
** End to End auto
* DoD Documentation
** Compléter le Tech Design
** [[Les RAML]]
** [[Documentation d'architecture (DAT)]]
** [[Documentation d'exploitation|Documentation d'exploitation (DEX)]]
** [[Documentation d'installation|Documentation d'installation (DIN)]]
** [[Documentation de migration|Documentation de migration (DMV)]] ( Script de montée de version ... )
** Le fichier README
** [[Mise à jour de l'ADR ( Log d'architecture )]]
** [[Listing des requêtes HTTP]]
** [[Documentation du workflow]]
** [[Documentation sur le modèle de données]]
* DoD Validation QA&UX
** Validation UX design
** Validation nominale
** Validation INT
** Validation ITREC
* DoD Validation PO
** Vérification documentaire
** Relecture finale

== Outils ==
Cette section recense les outils à disposition et leur usage dans le cadre du projet

== Jenkins ==

[https://jenkins.dev.programmevitam.fr/ Jenkins]

[https://jenkins.dev.programmevitam.fr/jenkins/job/doc-homepage/ws/index.html Tableau de Bord Vitam]

== Gestion des tickets ==

[https://assistance.programmevitam.fr/ Tuleap Bugtracker]

- Artefact USER STORIES est celui du projet

- Artefact DEMANDE PARTENAIRE est à suivre, recopier dans USER STORIES et à répondre aux partenaires

- Artefact Bugs = tickets de Bug de VITAM que notre recetteuse cherche à traiter avec l’Administration et l’équipe de dev.

== Contributions (Git) ==

[https://gitlab.dev.programmevitam.fr/vitam/vitam/merge_requests GitLab Vitam]

[https://github.com/ProgrammeVitam/vitam-ui/pulls Github Vitam UI]

Sert à suivre les états des MR. Une MR a le numéro du ticket Tuleap dans le titre (doit l'avoir en tout cas, sinon tu ne peux pas savoir si OK ou KO )

NB : Les accès sont gérés par les devOps

== Checkmarx ==
[https://checkmarx.preprod.programmevitam.fr/ Checkmarx]

Attention pour s’authentifier, choisir en option le : « VITAM OpenLdap »

== Sonar ==
[https://sonar.preprod.programmevitam.fr/dashboard?branch=develop&id=fr.gouv.vitam%3Aparent Tableau de bord (Preprod)]

== Squash ==
[https://squashtm.dev.programmevitam.fr/squash/login Tableau de bord Squash (multi projet)]

== Liens utiles ==
[https://www.programmevitam.fr/2023/11/13/vitam-en-ligne-interventions/ Webinaires]

ONBOARDING

2024-06-05T14:09:24Z

Jmminy : /* Accès aux différents sites */

== Accès aux différents sites ==
- [https://messagerie.culture.gouv.fr/ Messagerie Outlook]

- [https://assistance.programmevitam.fr/ Tuleap]

- Slack

- Teams

- [https://jenkins.dev.programmevitam.fr/ Jenkins]

- [https://gitlab.dev.programmevitam.fr/ GitLab de Vitam Core]

- [https://github.com/ProgrammeVitam/vitam-ui/ GitHub de Vitam UI]

- [https://github.com/ProgrammeVitam/vitam-itests/ GitHub de Vitam-itests]

- [https://www.programmevitam.fr/2023/11/13/vitam-en-ligne-interventions/ Webinaires]

MULTITEAM

2024-06-05T14:06:23Z

Jmminy : Ajout du lien vers les webinaires

== Présentation de l'équipe ==

- GHERIBI Lotfi

- RADEAU Daniel

- BERTOUL Raouaa

- SERIR Soufyane

- LEMAIRE Sandrine

- MINY Jean-Marie

- BERNARD Etienne

- TIZAOUI Mohamed

- BENARBIA Benaissa

- PARIS Alexandre

- NAJI Hossame

- ROBERT Maxime

- FATAN Souhaib

- JOSSE Isabelle

- VILLE Marion

- WELLHOFF Leo

[https://osmose.numerique.gouv.fr/jcms/p_2694773/fr/vitam-trombi Trombinoscope]

[https://docs.google.com/spreadsheets/d/12s-rlw3YEukqnjHTh9Kb9FhRfzY2J3hHdP81LBu_oHY/edit?pli=1#gid=0 Tableau de suivi des présences (Global)]

[https://docs.google.com/spreadsheets/d/1PiE6gQ2yFORZNtOYhkFugdmnMbPHhFdfCXapw5E-O6c/edit#gid=0 Planning Qualification Support]

== Procédures ==

[[Création d'une MR / PR]]

[[Review d'une MR / PR]]

[[Procédure d'installation Vitam Core pour développement local v.1.0]]

[[Formatage du code]]

== DOR : Definition Of Ready ==

* Estimation et criticité doivent être définie
* Le besoin et le context de l'US doit être compris par tous et retranscrit dans la description
* Un maximum de 7 critères d'acceptances
* Les maquettes doivent être à jour et terminées avec un lien FIGMA
* Il faut anticiper les scénarios UX
* Les traductions doivent être présentes
* Les US doivent être découpées en tâches
* Un tech design validé
* Identifier les aspects de refontes
* Identifier le travail sur les tests
** Quel niveau pour les TI
** Quel niveau pour les tests end to end ( TNR & Front selenium )
* Fournir des jeux de tests et des exemples
* Les dépendances entre US doivent avoir été identifiées

== DOD : Definition Of Done ==

* DoD Développement
** Tous les critères d'acceptances sont implémentés
** Le Build est valide
** Test nominaux sur INT / BAC à sable / Local
** Alimenter le changelog
** Fournir des jeux de données supplémentaires
** Fournir la requête REST pour les tests d'API
** Review du code OK
* DoD Testing
** TU ( Java et/ou Angular )
** TI
** TNR
** End to End auto
* DoD Documentation
** Compléter le Tech Design
** [[Les RAML]]
** [[Documentation d'architecture (DAT)]]
** [[Documentation d'exploitation|Documentation d'exploitation (DEX)]]
** [[Documentation d'installation|Documentation d'installation (DIN)]]
** [[Documentation de migration|Documentation de migration (DMV)]] ( Script de montée de version ... )
** Le fichier README
** [[Mise à jour de l'ADR ( Log d'architecture )]]
** [[Listing des requêtes HTTP]]
** [[Documentation du workflow]]
** [[Documentation sur le modèle de données]]
* DoD Validation QA&UX
** Validation UX design
** Validation nominale
** Validation INT
** Validation ITREC
* DoD Validation PO
** Vérification documentaire
** Relecture finale

== Outils ==
Cette section recense les outils à disposition et leur usage dans le cadre du projet

== Jenkins ==

[https://jenkins.dev.programmevitam.fr/ Jenkins]

[https://jenkins.dev.programmevitam.fr/jenkins/job/doc-homepage/ws/index.html Tableau de Bord Vitam]

== Gestion des tickets ==

[https://assistance.programmevitam.fr/ Tuleap Bugtracker]

- Artefact USER STORIES est celui du projet

- Artefact DEMANDE PARTENAIRE est à suivre, recopier dans USER STORIES et à répondre aux partenaires

- Artefact Bugs = tickets de Bug de VITAM que notre recetteuse cherche à traiter avec l’Administration et l’équipe de dev.

== Contributions (Git) ==

[https://gitlab.dev.programmevitam.fr/vitam/vitam/merge_requests GitLab Vitam]

[https://github.com/ProgrammeVitam/vitam-ui/pulls Github Vitam UI]

Sert à suivre les états des MR. Une MR a le numéro du ticket Tuleap dans le titre (doit l'avoir en tout cas, sinon tu ne peux pas savoir si OK ou KO )

NB : Les accès sont gérés par les devOps

== Checkmarx ==
[https://checkmarx.preprod.programmevitam.fr/ Checkmarx]

Attention pour s’authentifier, choisir en option le : « VITAM OpenLdap »

== Sonar ==
[https://sonar.preprod.programmevitam.fr/dashboard?branch=develop&id=fr.gouv.vitam%3Aparent Tableau de bord (Preprod)]

== Squash ==
[https://squashtm.dev.programmevitam.fr/squash/login Tableau de bord Squash (multi projet)]

== Liens utiles ==
[https://www.programmevitam.fr/2023/11/13/vitam-en-ligne-interventions/ Webinaires]

SUPPORT

2024-03-21T14:32:02Z

Jmminy : /* Processus de traitement des anomalies */

== Processus de traitement des anomalies ==

Pour assurer une bonne prise en charge et traitement des anomalies (bugs remonté par un utilisateur) , leur gestion fait l ’ objet d ’ un processus de traitement clairement défini et transparent vis - à - vis de tous les utilisateurs. Les engagements de délai ne s ’ appliquent que pour les porteurs et les utilisateurs financeurs. Il sera adossé à un outil de gestion des tickets de type <Tuleap> qui permettra à toute personne identifiée de visualiser toutes les anomalies remontées par son institution, et de suivre leur évolution en temps réel.

Le descriptif du processus, avec pour chaque étape le nom du statut associé dans l ’ outil de ticketing (cf. schéma ci - après), est le suivant (les actions étant effectuées par les équipes du titulaire sauf mention contraire) :

 EXT : lorsqu’un utilisateur découvre une anomalie sur son système, il cherche à déterminer si le problème provient de Vitam , de son intégration ou de son front - end.

 EXT : si le problème provient de Vitam, l ’ utilisateur crée un scenario permettant de reproduire l ’ anomalie sur un environnement de type pré - production (ce scenario devra pouvoir être joué sur l ’ environnement de recette de l ’ équipe Vitam).

 EXT : ensuite, l ’ utilisateur ouvre un ticket sur l ’ outil de gestion des tickets avec un degré de gravité, le scénario et le cas échéant les fichiers permettant de reproduire le bug avec le numéro de version du logiciel Vitam utilisée ⇒ statut du ticket : ouvert .

 Vitam : l ’ équipe Vitam prend en charge le ticket avec les sous - étapes suivantes :

- En prenant comme référence le degré de gravité donné par l ’ auteur du ticket, la personne en charge de la recette doit commencer le traitement de ce ticket avant la fin du délai de prise en compte correspondant à son degré de gravité ⇒ statut du ticket : pris en compte .

- Le traitement commence par la reproduction de l ’ anomalie sur un environnement de recette :

▪ En cas de difficulté, la personne en charge de la recette prend contact avec l ’ émetteur du ticket ⇒ statut du ticket : en cours de reproduction . L ’ auteur du ticket et la personne en charge de la recette font tout leur possible pour réduire au maximum le temps de qualification de l ’ anomalie.

▪ Quan d l ’ anomalie est reproduite ⇒ statut du ticket : qualifié .

▪ Si l ’ anomalie n ’ est pas reproductible mais qu’elle est clairement identifiée à partir des fichiers envoyés (ex : logs) ⇒ statut du ticket : qualifié .

- Une fois dans l ’ état « qualifié », le ticket es t étudié par un membre de l ’ équipe interministérielle qui valide le niveau de gravité et vérifie que cette anomalie n’est pas une demande d ’ évolution. Toutes les modifications sur le ticket sont tracées dans l ’ outil et l ’ émetteur du ticket est informé de t outes les actions sur ce ticket. En cas de désaccord sur la prise en charge du ticket par l ’ équipe de la MAC Vitam, l’auteur peut faire appel à la procédure d ’ escalade pour demander à ce que ce ticket fasse l ’ objet d ’ une étude approfondie. - Analyse détaillé e :

▪ Si le problème touche à la procédure d ’ installation / de paramétrage, l ’ équipe d ’ intégration prend contact avec l ’ utilisateur pour trouver une solution adaptée ⇒ statut du ticket : en cours d ’ analyse .

▪ Si le problème provient du code, une analyse est la ncée pour déterminer la cause ⇒ statut du ticket : en cours d ’ analyse .

- Solution de contournement :

▪ Si une solution de contournement, qui ne résout pas complètement le problème mais permet au projet de fonctionner pendant une phase transitoire est possible, celle - ci est partagée par l ’ intermédiaire de l ’ outil de gestion des tickets à l ’ utilisateur.

▪ EXT : l ’ utilisateur teste, et le cas échéant met en place cette solution de contournement. L ’ utilisateur partage les résultats de ces travaux dans les commentaire s du ticket. En cas de problème, il contacte la personne en charge de la recette pour un traitement rapide de sa demande.

- Solution définitive :

▪ Vitam : si une solution définitive est identifiée et doit faire l ’ objet d ’ un développement, elle est prise en compte par les équipes de développement avec un délai de livraison qui dépend de la gravité de l ’ anomalie ⇒ statut du ticket : en cours de développement .

▪ Vitam : la version corrective qui comporte la correction de l ’ anomalie passe par l ’ ensemble des tests automatiques associés ⇒ statut du ticket : résolution livrée . Le ticket indique la ou les versions qui comportent le correctif.

- EXT : l ’ utilisateur applique le correctif, formalise ses retours sur l ’ outil de gestion des tickets et demande la fermeture du ticket.

▪ Fermeture du ticket si l ’ anomalie est corrigée ⇒ statut du ticket : fermé .

▪ Demande de réouverture du ticket si l ’ anomalie persiste avec :

 Demande de prise en charge urgente si l ’ anomalie est identique. La personne en charge de la recette contacte l ’ émetteur du ticket pour trouver rapidement une solution au problème ⇒ statut du ticket : qualifié .

 Ouverture d ’ un nouveau ticket en cas d ’ apparition de problèmes liés au correctif. Si l ’ utilisateur n ’ a pas mis à jour le statut du ticket suite à son passage en « résolution livrée », une relance automatique sera faite régulièrement à l ’ auteur du ticket pour le clôturer. Faute de retour de la part de l ’ utilisateur dans un délai de 1 mois, le ticket est réputé fermé.

- Le délai de création d'un ticket de niveau 1 (anomalie bloquante) est fixé à 2h maximum pendant les jours ouvrés dans les horaires de 9h à 18h.

- Concernant les tickets créés, tous les tickets ouverts doivent être mis à jour régulièrement ( a minima une fois par jour pour les anomalies bloquantes et une fois par semaine pour toutes les autres anomalies ) avec des relances par téléphone vers les personnes devant intervenir (toutes ces relances seront tracées dans l'outil de gestion de ticket).

SUPPORT

2024-03-21T14:29:31Z

Jmminy : /* Processus de traitement des anomalies */

== Processus de traitement des anomalies ==

Pour assurer une bonne prise en charge et traitement des anomalies (bugs remonté par un utilisateur) , leur gestion fait l ’ objet d ’ un processus de traitement clairement défini et transparent vis - à - vis de tous les utilisateurs. Les engagements de délai ne s ’ appliquent que pour les porteurs et les utilisateurs financeurs. Il sera adossé à un outil de gestion des tickets de type <Tuleap> qui permettra à toute personne identifiée de visualiser toutes les anomalies remontées par son institution, et de suivre leur évolution en temps réel.

Le descriptif du processus, avec pour chaque étape le nom du statut associé dans l ’ outil de ticketing (cf. schéma ci - après), est le suivant (les actions étant effectuées par les équipes du titulaire sauf mention contraire) :

 EXT : lorsqu’un utilisateur découvre une anomalie sur son système, il cherche à déterminer si le problème provient de Vitam , de son intégration ou de son front - end.

 EXT : si le problème provient de Vitam, l ’ utilisateur crée un scenario permettant de reproduire l ’ anomalie sur un environnement de type pré - production (ce scenario devra pouvoir être joué sur l ’ environnement de recette de l ’ équipe Vitam).

 EXT : ensuite, l ’ utilisateur ouvre un ticket sur l ’ outil de gestion des tickets avec un degré de gravité, le scénario et le cas échéant les fichiers permettant de reproduire le bug avec le numéro de version du logiciel Vitam utilisée ⇒ statut du ticket : ouvert .

 Vitam : l ’ équipe Vitam prend en charge le ticket avec les sous - étapes suivantes :
- En prenant comme référence le degré de gravité donné par l ’ auteur du ticket, la personne en charge de la recette doit commencer le traitement de ce ticket avant la fin du délai de prise en compte correspondant à son degré de gravité ⇒ statut du ticket : pris en compte .
- Le traitement commence par la reproduction de l ’ anomalie sur un environnement de recette : ▪ En cas de difficulté, la personne en charge de la recette prend contact avec l ’ émetteur du ticket ⇒ statut du ticket : en cours de reproduction . L ’ auteur du ticket et la personne en charge de la recette font tout leur possible pour réduire au maximum le temps de qualification de l ’ anomalie.
▪ Quan d l ’ anomalie est reproduite ⇒ statut du ticket : qualifié .
▪ Si l ’ anomalie n ’ est pas reproductible mais qu’elle est clairement identifiée à partir des fichiers envoyés (ex : logs) ⇒ statut du ticket : qualifié .
- Une fois dans l ’ état « qualifié », le ticket es t étudié par un membre de l ’ équipe interministérielle qui valide le niveau de gravité et vérifie que cette anomalie n’est pas une demande d ’ évolution. Toutes les modifications sur le ticket sont tracées dans l ’ outil et l ’ émetteur du ticket est informé de t outes les actions sur ce ticket. En cas de désaccord sur la prise en charge du ticket par l ’ équipe de la MAC Vitam, l’auteur peut faire appel à la procédure d ’ escalade pour demander à ce que ce ticket fasse l ’ objet d ’ une étude approfondie. - Analyse détaillé e : ▪ Si le problème touche à la procédure d ’ installation / de paramétrage, l ’ équipe d ’ intégration prend contact avec l ’ utilisateur pour trouver une solution adaptée ⇒ statut du ticket : en cours d ’ analyse . ▪ Si le problème provient du code, une analyse est la ncée pour déterminer la cause ⇒ statut du ticket : en cours d ’ analyse .
- Solution de contournement :
▪ Si une solution de contournement, qui ne résout pas complètement le problème mais permet au projet de fonctionner pendant une phase transitoire est possible, celle - ci est partagée par l ’ intermédiaire de l ’ outil de gestion des tickets à l ’ utilisateur.
▪ EXT : l ’ utilisateur teste, et le cas échéant met en place cette solution de contournement. L ’ utilisateur partage les résultats de ces travaux dans les commentaire s du ticket. En cas de problème, il contacte la personne en charge de la recette pour un traitement rapide de sa demande.

- Solution définitive :
▪ Vitam : si une solution définitive est identifiée et doit faire l ’ objet d ’ un développement, elle est prise en compte par les équipes de développement avec un délai de livraison qui dépend de la gravité de l ’ anomalie ⇒ statut du ticket : en cours de développement . ▪ Vitam : la version corrective qui comporte la correction de l ’ anomalie passe par l ’ ensemble des tests automatiques associés ⇒ statut du ticket : résolution livrée . Le ticket indique la ou les versions qui comportent le correctif.

- EXT : l ’ utilisateur applique le correctif, formalise ses retours sur l ’ outil de gestion des tickets et demande la fermeture du ticket.
▪ Fermeture du ticket si l ’ anomalie est corrigée ⇒ statut du ticket : fermé .
▪ Demande de réouverture du ticket si l ’ anomalie persiste avec :

 Demande de prise en charge urgente si l ’ anomalie est identique. La personne en charge de la recette contacte l ’ émetteur du ticket pour trouver rapidement une solution au problème ⇒ statut du ticket : qualifié .

 Ouverture d ’ un nouveau ticket en cas d ’ apparition de problèmes liés au correctif. Si l ’ utilisateur n ’ a pas mis à jour le statut du ticket suite à son passage en « résolution livrée », une relance automatique sera faite régulièrement à l ’ auteur du ticket pour le clôturer. Faute de retour de la part de l ’ utilisateur dans un délai de 1 mois, le ticket est réputé fermé.

- Le délai de création d'un ticket de niveau 1 (anomalie bloquante) est fixé à 2h maximum pendant les jours ouvrés dans les horaires de 9h à 18h.

- Concernant les tickets créés, tous les tickets ouverts doivent être mis à jour régulièrement ( a minima une fois par jour pour les anomalies bloquantes et une fois par semaine pour toutes les autres anomalies ) avec des relances par téléphone vers les personnes devant intervenir (toutes ces relances seront tracées dans l'outil de gestion

SUPPORT

2024-03-21T14:02:06Z

Jmminy : Page créée avec « == Processus de traitement des anomalies == Pour assurer une bonne prise en charge et traitement des anomalies (bugs remonté par un utilisateur) , leur gestion fait l ’ objet d ’ un processus de traitement clairement défini et transparent vis - à - vis de tous les utilisateurs. Les engagements de délai ne s ’ appliquent que pour les porteurs et les utilisateurs financeurs. Il sera adossé à un outil de gestion des tickets de type <Tuleap> qui permettr... »