Des exemples d’indicateurs ponctuels mis en place sont disponibles dans le tableau 6.2.
Les vacances scolaires ont été exclues du comptage pour les indicateurs faisant référence à des délais.

   TABLE 6.2: Récapitulatif des indicateurs ponctuels.

Ces indicateurs seront diffusés, après chaque mise à jour, à l’ensemble de l’équipe PIC.

Le Tableau de Bord est un outil de suivi permettant au PIC de suivre visuellement l’évolution de la qualité grâce à l’affichage des états de tous les indicateurs.

Cet outil sera mis à jour de manière hebdomadaire par le Responsable Indicateurs et sera archivé dans le référentiel Qualité.

Pour évaluer le management de la Qualité au sein du PIC, des audits et inspections auront lieu chaque semestre. La conformité du PIC et du SMQ sera vérifiée sur plusieurs points :

• les dispositions prises par la direction du PIC (engagements, Plan Qualité, Plan de Gestion des Configurations);
• la norme ISO 9001:2015 ;
• la Système de Management de la Qualité de l’Unité P3 du Département ASI.

Toute remarque ou non-conformité fera l’objet d’une Fiche de Fait Technique.
Il est fortement conseillé à l’équipe PIC de prendre rendez-vous avec l’auditeur après les résultats de l’inspection technique et de l’audit qualité afin de s’assurer que toutes les remarques ont bien été comprises et ainsi effectuer des actions correctives efficaces.

Le Responsable Développement aura à charge d’assurer la surveillance de la qualité du code grâce à des outils de vérification de règles de codage.
Cette vérification aura lieu sur le code produit à l’aide des outils fournis par Jenkins et So-narQube. Il est à noter qu’une inspection technique peut être programmée par l’Unité P3.

Le bon suivi de la qualité sera garanti par un système de traitement des Faits Techniques(FT). Ce traitement va permettre, en cas d’erreurs,de remarques, de points à revoir ou de problèmes internes au projet, de les corriger en s’assurant que ces modifications auront bien été prises en compte. Une Fiche de Fait Technique (FFT) est alors crée.

Un FT est un événement nécessitant une traçabilité suite à la détection d’une non-conformité. Un FT peut avoir différentes origines :

• Le client, pour tout ce qui relève des remarques, points à modifier, etc. ;
• L’équipe PIC, pour les problèmes internes de planning, informatiques, ou encore une évolution d’un document ;
• Un audit ;
• Une inspection.

Lorsqu’un FT est détecté, il y a création d’une FFT sur la plateforme Redmine, celle-ci permet :

• De connaître les détails du FT ;
• D’en connaître l’état : en cours, résolu, fermé ou rejeté (si le FT n’est pas valide) ;
• D’en conserver une trace ;
• D’en effectuer une analyse à froid après une Commission de Traitement des Faits Techniques (CTFT).

La source est définie dans le champ « Tracker » d’un FT par :

• Réclamation client ;
• Non-conformité mineure (Actualisation, anomalies mineures) ;
• Non-conformité majeure (Anomalie majeure, remarque suite à un audit/inspection

technique).

Chaque source peut entraîner différentes actions :

• Non-conformité mineure : action curative car elle ne nécessite pas d’analyse de causes ;
• Non-conformité majeure : une analyse de causes et la mise en place d’action curati-ves/corrective mais préférentiellement corrective;
• Réclamation client : même traitement que pour une non-conformité majeure plus la mise en place d’une communication client.
  

Le type est indiqué en titre par :

• Anomalie ;
• Remarque ;
• Non-conformité ;
• Actualisation ;
• Demande d’évolution ;
• Demande de Correction.

La gravité de la FFT est défini dans le champ priorité. Elle devra être évaluée selon cinq degrés :

• Bas, n’implique aucun retard dans le déroulement du projet ;
• Normal, pourrait retarder la tâche mais pas le projet ;
• Haut, risque certainement d’entraîner un retard dans le projet ;
• Urgent, entraînera un retard dans le projet ;
• Immédiat, bloque le déroulement.

Un FT relève d’un écart. Si plusieurs écarts sont remarqués sur un même document, il y a possibilité de regrouper ces écarts dans une même FFT.

La correction d’un FT est tracée dans une nouvelle demande sur la plateforme Redmine. Elle sera ensuite associée comme sous tache de la FFT qu’elle corrige. Contrairement à l’ancien système de gestion des FFT et OC (jusqu’à la FFT35), il n’est désormais plus possible qu’un seul Ordre de Correction (OC) traite plusieurs FFT.
Une FFT sera clôturée si l’OC correspondant est clôturé. Pour pouvoir clôturer un OC, le vérificateur doit préalablement avoir vérifié que l’ensemble des mesures correctives a été réalisé et que les actions préventives ont été amorcées (en cours ou terminées). Si le document concerné par l’Ordre de Correction est soumis à approbation alors il devra être de nouveau approuvé avant la clôture.
À noter que les conditions de clôture de l’Ordre de Correction doivent figurer sur la FFT ainsi que les documents concernés.
Le membre correcteur sera précisé dans le champ “Assigné à”.
Pour un OC, le correcteur, le vérificateur et la personne chargée de la clôture de l’OC doivent être différentes.

Il existe une CTFT qui permet une gestion efficace des FT. Une CTFT est organisée afin de décider des actions et mesures correctives à prendre à son encontre(émission des Fiche d’Ordre de Correction). Les CTFT auront lieu toutes les deux semaines, fréquence qui sera adaptable selon le nombre de FFT à traiter.
Pendant une CTFT, les membres de la CTFT vont étudier les différentes FFT en cours.
Une CTFT est composée :

• Des auteurs des Fiches de Fait Technique si possible ;
• Des responsables de corrections si nécessaire ;
• Des vérificateurs ;
• De la personne en charge de la clôture des OC : le Responsable de la Gestion des Configurations.

En général, le Responsable Qualité et le Chef PIC occupent chacun un rôle dans la CTFT. De manière générale, la personne en charge de clôturer les FFT et les FOC est le RGC.

La figure 6.1 présente le cycle que subira un FT.

TODO : fig61.png

                  FIGURE 6.1 – Cycle des FT

Les CTFT sont composées du Chef PIC et du Responsable Qualité mais peut demander l’aide d’un ou plusieurs membres du PIC suivant les savoirs requis pour élaborer les correc- tions. Les corrections d’un FT sont récapitulées dans un Ordre de Correction (OC), dont la création est notée dans un Compte-Rendu. Cette commission se charge aussi de la clôture des Ordre de Correction vérifiés si ceux-ci ont répondu au problème pour lequel ils ont été créés.

Les actions curatives visent à éliminer une non-conformité détectée le plus rapidement possible. Il s’agit ici de soigner les symptômes sans se soucier des causes du problème. En cas de détection d’un FT ou d’une non-conformité, les actions curatives ne sont pas suffisantes, il faut au minimum une action corrective.

Une action corrective est une mesure prise afin d’éliminer les causes d’une non-conformité ou d’une FFT. La mise en place d’une action corrective repose sur une analyse poussée des causes qui assure une disparition totale du problème. La méthode conseillée est la méthode des « 5 pourquoi ». Afin de garantir l’amélioration continue, il est important d’avoir au moins une action corrective dans chaque Ordre de Correction.

D’après la norme ISO 9001:2015, une action préventive est : “Une action visant à éli- miner la cause d’une non-conformité potentielle ou d’une autre situation potentielle indési- rable”. Les actions préventives sont mises en place en prévision d’un problème qui pourrait potentiellement apparaître. Il est indispensable de procéder à la rédaction d’une FFT et à une analyse des causes avant de définir une action préventive. L’avantage de ces actions est de prévenir l’apparition des problèmes et ainsi assurer un bon fonctionnement du PIC sans accroc.

La réalisation des produits se fera avec la méthode Agile mais toujours adaptée aux normes de la DGQ2.
Les différentes phases du développement des produits sont spécifies dans la partie 4.1 Planification du projet.

La phase de démarrage a lieu au début du premier semestre et a pour but de lancer le projet et d’optimiser l’environnement dans lequel EPICLEARNING évoluera. Plus précisé- ment, cette phase permettra :

• L’installation de l’équipe dans la salle PIC qui lui est destinée ;
• La mise en place du réseau et de l’infrastructure logicielle et matérielle dans la salle ;
• La mise en place de l’environnement de développement ;
• L’étude des besoins du client par des réunions et des échanges de mails avec ce dernier ;
• La formation de l’équipe aux diverses technologies qui seront utilisées pendant le PIC ;
• L’initialisation des deux dossiers de spécification.

Chaque sprint commence par une réunion de planification de sprint avec Youen C HÉNÉ et EPICLEARNING .
Durant cette réunion, le client et l’équipe choisissent quelles fonctionnalités vont être le coeur du lot à venir et si certaines fonctions du lot précédent sont à retravailler.

Le sprint commence par une phase de spécification durant laquelle les documents suivants doivent être mis à jour.

Ce document décrit les fonctionnalités que le produit doit réaliser ainsi que la façon dont celles-ci sont implémentées. Il sera validé par le client et les fonctionnalités du lot à venir y sont rajoutés lors de la mise à jour du début de sprint.

Il définit la campagne de tests qui sera mise en place à fin de valider le respect du DS par le produit. l’équipe PIC à aussi l’obligation de conseil sur le client concernant les points de validation peu précis.

Cette phase a pour but de mettre à jour le code source du framework afin d’intégrer les nouvelles fonctionnalités demandées par le client pour le sprint. Cette phase se décompose en 3 étapes :

• Phase de conception détaillée ;
• Phase de codage ;
• Phase de tests unitaires.

Une fois les fonctions du lot définies, on met à jour les documents suivants :

Le Document de Conception regroupe la conception préliminaire et la conception détaillée. Il définit premièrement l’architecture générale du programme et les illustre via des diagrammes UML 2.0. Ce document se base sur les choix réalisés dans le DS.Le document de conception détaillé (DCD) définit l’architecture détaillée du programme. Il contient la définition des attributs de chacune des classes à développer et le pseudo-code commenté des méthodes non-triviales. S’il n’est pas nécessaire de détailler toutes les méthodes et tous les attributs des classes d’un package, ce choix doit être justifié.

Ce document décrit brièvement les tests unitaires et d’intégration mis en place pour ce lot. Les tests unitaires permettent de vérifier que chaque fonction fait bien, unitairement, ce qu’il est prévu qu’elle fasse. Les tests d’intégration permettent de vérifier la cohésion et le bon fonctionnement des composants une fois reliés entre eux. Il contient également les tests de non régréssion. Ces tests sont mis en place à la fin de chaque sprint afin de vérifier que toutes les fonctions développées par le passé restent fonctionnelles malgré les modifications durant le sprint.

Cette étape consiste en une traduction dans un langage de programmation des méthodes écrites dans le Document de Conception et l’ajout de commentaires tout en les limitant. La syntaxe du code suivra les règles de programmation déterminées au préalable et détaillées en annexe K.

Le code source sera testé grâce aux programmes de tests précédemment créés. Ces programmes de tests pourront être améliorés au cours de cette phase afin de perfectionner les fonctions codées par les développeurs de l’équipe, ceci les poussant à optimiser le code produit.

La phase de réalisation commence par la programmation des tests d’intégration et des tests unitaires détaillés dans le PT. La programmation des tests avant l’écriture du code testé permet de guider la programmation. Tout écart du code par rapport aux tests d’intégration dû à une mauvaise conception entraîne le retour à la phase de conception afin de corriger la mauvaise conception avant de pouvoir passer à nouveau à la phase de réalisation. Si un test unitaire ne fonctionne pas à cause d’une erreur de conception jugée bénigne, la conception détaillée doit être mise à jour avec les modifications apportées à la fonction qui pose problème.
Les résultats produits par les tests seront enregistrés et tracés (version du code, test, date…) afin de conserver la preuve que le code fonctionne ou que les soucis éventuels ont été réglés au fur et à mesure des tests.

Cette phase a pour but d’analyser les fonctions du produit déjà définies pendant le sprint et de valider le prototype du lot avant de le livrer au travers des tests de validation du PTV. Si des tests ne passent pas, l’équipe doit proposer des solutions pour corriger le problème. De la même manière que précédemment, l’exécution et les résultats des tests seront conservés dans des journaux de tests.
Si le code source ne passe pas les tests de validation ; il faudra retourner à la phase de spécification afin de corriger les spécifications et les mettre en accord avec le DS.

À chaque semestre l’équipe EPICLEARNING sera évaluée lors de 2 revues de PIC. Lors de ces revues seront normalement présents :

• Le représentant du client : Youen CHÉNÉ ;
• Le tuteur pédagogique : Gilles GASSO ;
• Le tuteur qualité : Benjamin CŒLHO DE MATOS ;
• Le directeur qualité de l’unité P3 : Pascal MESLIER .

La revue se déroulera de la façon suivante :

• Présentation du sujet ;
• Avancement du projet ;
• Gestion de la qualité du projet ;
• Séance de questions/réponses.

Tous les documents produits par l’équipe PIC passeront par un processus de vérification, validation, approbation puis diffusion.

Avant de commencer la phase de vérification d’un document, il faut s’assurer que le ré- dacteur a bien signalé que la rédaction du document est terminée.
Le vérificateur, qui est un membre de l’équipe PIC n’ayant pas rédigé le document, doit s’assurer que :

• Le document est cohérent avec les autres documents en référence ;
• L’orthographe du document est correcte ;
• Le document est lisible et bien mis en forme ;
• Le document respecte bien les conventions de nommage inscrites dans le Plan Qualité et le Plan de Gestion des Configurations.
  

Chaque document doit contenir une table de références contenant des références vers des liens utiles à la compréhension du document. La référence doit être complète et conforme et comporter le numéro de version du document.

Enfin, le vérificateur doit :

• Le signaler sur PGPic ;
• Le signaler aux autres membres de l’équipe ;
• Signer le document papier ou par courriel ;
• Modifier le document numérique pour indiquer la date et qu’il a appliqué son visa.

Le visa du document numérique peut être matérialisé de différents façons :

• “intranet” : le visa est matérialisé seulement sur PGPic ;
• “courriel” : le visa a été matérialisé par courriel ;
• “signé” : le visa a été matérialisé sur le document papier par une signature.

Après s’être assuré que la vérification du document est bien terminée, le validateur doit s’assurer de :

• La pertinence du document ;
• La complétude du contenu ;
• Modifier le document afin d’indiquer la date et d’appliquer son visa.
  

Le visa du document numérique peut être matérialisé de différents façons :

• “intranet” : le visa est matérialisé seulement sur PGPic ;
• “courriel” : le visa a été matérialisé par courriel ;
• “signé” : le visa a été matérialisé sur le document papier par une signature.

Les documents ayant une portée extérieure doivent être approuvés par la personne concernée. Le document devient alors un enregistrement.

Le tuteur pédagogique et/ou le tuteur qualité devront approuver par mail chaque compte- rendu de réunion rédigé à la suite d’une réunion en leur présence.

Le client devra approuver les documents suivants :

• Le Dossier de Spécifications ;
• Le Plan de Tests de Validation.

Le Chef PIC doit vérifier que tous les fichiers d’un lot sont présents lors de la livraison de celui-ci.
Il doit également vérifier que l’archive est bien conforme au Cahier de Recette et créer l’État de Configuration correspondant à la livraison avec tout ce qui a été livré. Le Chef PIC doit également rédiger le Procès-Verbal de livraison.
La livraison se fait sur le Git du client. Un lot est considéré comme livré à la fin d’un sprint. Avant chaque livraison, l’équipe PIC doit valider et vérifier le lot. La validation consiste à valider la conformité du lot avec les exigences du client. Il faut que le lot soit conforme au Dossier de Spécifications. La vérification consiste à s’assurer que tous les tests décrits dans le Plan de Tests de Validation soient correctement passés.

Il est indispensable de mettre en place un dispositif de vérification, surveillance et validation du produit.

Une séance de test de validation permet de vérifier que toutes les spécifications sont respectées. Cette phase est décrite dans le Plan de Tests de Validation et doit être approuvée par le client. Le déroulement de cette séance est le suivant :

• Le pré-examen (optionnel) ;
• La séance de recette provisoire ;
• La période probatoire ;
• La séance de recette définitive.
  

Pré-examen
Cette phase n’est pas obligatoire. Cette période entre trois jours et quatre semaines et se déroule juste après la phase d’intégration. Pendant cette période, le client analyse minutieusement le produit et répond à un questionnaire afin de noter les manquants.

Séance de recette provisoire
Durant cette séance, les conditions qui doivent être satisfaites sont :

• Exécution de la totalité des essais prévus dans le Cahier de Recette Le client effectue les tests sur le produit en s’attachant à suivre le Cahier de Recette, page par page ;
• Établir une liste exhaustive des écart Chaque remarque effectuée doit être traitée par une Fiche de Fait Technique dont la référence apparaîtra dans le Cahier de Recette, les Fiche de Fait Technique doivent également faire référence au Cahier de Recette.

Suivant les résultats obtenus, le client peut ne pas valider cette séance ou la valider et reporter des remarques dans le lot suivant. Si le client n’est pas là physiquement et que le Cahier de Recette est déroulé à distance, une nouvelle version du Cahier de Recette annotée est rédigée par l’équipe PIC et est envoyée pour approbation au client.

Période probatoire
Il s’agit d’une période minimum de trois jours consacrée à l’expérimentation du produit par le client et à la formation des utilisateurs. Lors de cette période, le client peut être amené à émettre des Fiche de Fait Technique. La durée exacte de cette période est précisée dans le Plan de Tests de Validation.

Séance de recette définitive
Cette séance est similaire à la séance de recette provisoire. Durant cette séance, toutes les conditions suivantes doivent être satisfaites :

• exécution de la totalité des tests prévus dans le Cahier de Recette ;
• aucun écart observé.

Les scenarios spécifiques visent à vérifier la résolution des Fiche de Fait Technique émises lors de la séance de recette provisoire ou lors de la période probatoire. À la fin de la séance,quatre situations peuvent se présenter :

• Le client valide la séance ;
• Le client valide la séance sous réserve que toutes les remarques émises soient traitées, la recette définitive est acceptée quand la dernière réserve est levée ;
• Le client valide la séance, et toutes les remarques émises seront de nouveau soumises à évaluation dans le prochain lot ;
• Le client ne valide pas la séance, elle est alors ajournée et une nouvelle période probatoire est programmée, qui sera suivie d’une séance de recette définitive. Cette séance se déroule normalement chez le client.

La période de garantie contient les jeux d’essais, les journaux de tests, les résultats des essais, les résultats attendus. Tous les PV d’acceptation ou d’ajournement signés par le client lors des séances de recette (provisoire et définitive) sont des informations documen- tées au sens de la norme ISO 9001:2015.

Une séance de tests de validation vise à montrer que chaque élément des spécifications est réalisé. Un parcours d’un CDR est pour cela nécessaire. À la fin de la séance et pour chaque recette, un PV est produit pour résumer les résultats. Les différentes étapes d’une séance de validation sont décrites dans le PTV. Les différents éléments décrits ci-dessous ne sont cités qu’à titre indicatif.

Installation Cette phase vise à contrôler les procédures :

• de génération de produit ;
• d’installation ;
• de mise en service ;
• d’initialisation.

Interfaces Une vérification de la présence et de la conformité de toutes les interfaces spécifiées est faite par le PIC :

• écrans, menus et dialogues ;
• états imprimés, traces ;
• messages d’erreur ;
• liens entre systèmes (formats de message, protocoles) ;
• fichiers en entrée, sortie.

IHM Une vérification est faite par le PIC de :

• l’interaction avec les autres systèmes ;
• l’interaction avec les autres logiciels.

Fonctionnalités Le PIC doit effectuer une vérification :

• de l’existence des fonctions annoncées ;
• de l’exécution correcte dans des conditions normales d’utilisation des fonctions annoncées ;
• des différents modes de fonctionnement.

Performances Le PIC doit vérifier que le produit satisfait les contraintes de performance dans des conditions normales d’utilisation et de fonctionnement en pleine charge :

• temps de calcul, réponse et exécution ;
• précision relative ou absolue ;
• espace mémoire ;
• débit de transmission ;
• capacité limitée en fichiers, terminaux, utilisateurs, tâches, traitements simultanés.

Robustesse - Modes dégradés L’objectif est de contrôler qu’une erreur accidentelle pro-voquée par un opérateur ne peut affecter les données ou le fonctionnement du produit. Une vérification de la sûreté de fonctionnement est faite par le PIC. Il s’agit de connaître l’aptitude à assurer la poursuite des opérations malgré des conditions de fonctionnement non nominales. Le PIC effectue un contrôle de robustesse : fonctionnement nominal (sans défaillance) malgré l’apparition de défauts (externes ou internes). Le PIC doit également contrôler les modes dégradés. Il s’agit des fonctionnements de sécurité, dégradés par rapport au mode nominal (fonction, performance, etc.) :

• détection des conditions de passage ;
• fonctions et performances du mode dégradé ;
• retour au mode nominal après disparition des perturbations.

Sécurité Ceci permet de contrer les tentatives des pirates et l’accès aux données confidentielles par des tierces personnes. Configuration Le PIC devra s’assurer que le produit fonctionne correctement dans toutes les configurations indiquées.

Configuration Le PIC devra s’assurer que le produit fonctionne correctement dans toutes les configurations indiquées.

Compatibilité - Conversion Une vérification de l’aptitude du produit à être utilisé en remplacement de systèmes existants ou de versions précédentes est faite par le PIC. Suite à cela, le PIC doit s’assurer que la validation des procédures de conversion a été faite. Enfin,au moyen d’une exécution en parallèle, le PIC vérifie que le produit actuel renvoie un résultat identique aux versions précédentes.

Exploitation L’objectif est de vérifier que :

• le produit est exploitable ;
• les procédures d’exploitation fonctionnent correctement ;
• leur mise en œuvre est conforme au manuel d’exploitation.

La phase de garantie commence lors de l’approbation par le client de la réception définitive du produit. Il s’agit de la durée pendant laquelle le client peut exiger la réparation gratuite de vices cachés.

La satisfaction du client par rapport au PIC est mesurée grâce à des questionnaires fournis puis transmis par l’Unité P3 au client. Ces questionnaires contiennent des questions permettant de mesurer la satisfaction du client sur différents axes :

• La communication avec l’équipe PIC
• Les respect des délais de livraison des différents lots
• La qualité des différents livrables

C’est la Revue de Direction qui fixe les Objectifs Qualité, ceux-ci sont susceptible de chan-ger en fonction des remarques du client et des nouvelles mesures potentielles exprimées par la Direction Qualité.
Le client devra répondre à chaque question en donnant son appréciation sur une échelle de 0 à 20. Les questionnaires sont sous forme d’enquête, réalisables directement sur internet. Le client sera amené à remplir un questionnaire lors de chaque revue PIC, il aura donc 4 questionnaires à remplir tout au long du picCourt. Les questionnaires lui seront envoyés par l’Unité P3. Le Responsable Qualité devra récupérer les questionnaire par mail auprès de l’Unité P3.
Si des insatisfactions sont remarquées, le Chef PIC devra prendre contact avec le client pour mettre en place des mesures afin d’améliorer sa satisfaction.

La satisfaction du client peut également être mesurée grâce à des questionnaires locaux. Ces questionnaires sont crées par l’équipe picCourt et auront pour but de mesurer la réali- sation des Objectifs Qualité définis dans le Plan Qualité. Ces questionnaires, de type local ne sont pas obligatoires. Ils ne doivent contenir aucune question similaire à celles du ques- tionnaire de l’Unité P3 et les questions doivent être cohérentes avec les objectifs à mesurer.

Si des insatisfactions sont remarquées au retour du questionnaire, l’équipe PIC devra ré- diger une Fiche de Fait Technique (FFT). Un Ordre de Correction sera rédigé s’il est possible d’apporter une correction à l’insatisfaction.

Des remarques peuvent être émises par le client tout au long du projet PIC. Une re- marque n’a pas d’influence sur la satisfaction du client. Un remarque doit être corrigée selon le cycle correctif : une Fiche de Fait Technique (FFT) doit être créée puis traitée en Commis- sion de Traitement de Faits Techniques. La Fiche de Fait Technique sera ensuite clôturée après avoir clôturé les Ordres de Correction établis.

Des réclamations peuvent être émises par le client tout au long du projet PIC. Une récla- mation a une influence sur la satisfaction du client. C’est pourquoi il faut mettre en place un système correction particulier afin de traiter la réclamation rapidement. Premièrement une Fiche de Fait Technique est créée. Une Commission de Traitement des Faits Techniques est organisée juste après l’émission de la Fiche de Fait Technique, le client est informé par mail de cette Commission de Traitement des Faits Techniques afin d’être rassuré. Un Ordre de Correction est rédigé et est envoyé au client qui pourra comme cela voir les mesures prises. La communication avec le client est renforcée pour pouvoir accompagner le client et le rassurer.

• 1 grand bureau;
• 6 petits bureaux;
• 1 table;
• 11 chaises;
• 2 poubelles;
• 1 armoire;
• 1 porte-manteaux (bancal).

• câble en Y pour double sortie DVI : 1 ;
• HP LaserJet P2055d (CNCJB83452) ;
• Epson Perfection V37 ;
• Mustek 1800 UB ;
• Cable imprimante USB ;
• Cable USB, A mâle vers B mâle : 5 ;
• 22” Iiyame ProLite X24585WS ;
• 24” Dell E248WFP CZ-0G274H-74263-93d-172s ;
• 24” Dell E248WFP CZ-0G274H-74263-93d-170s ;
• 24” Dell E248WFP CZ-0G274H-74263-93d-179s ;
• 24” Dell E248WFP CZ-0G274H-74263-93d-16ys ;
• 24” Asus VH242 A3LMIZ083771 ;
• 24” Asus VH242 A3LMIZ083761 ;
• 24” Asus VH242 A3LMIZ084555 ;
• 24” Asus VH242 A3LMIZ084538 ;
• 24” Asus VH242 A3LMIZ084519 ;
• 24” Dell ST2420 CN-09WTC7-74261-135-0DYU ;
• 24” Dell ST2420 CN-09WTC7-74261-135-0E8U ;
• 24” Dell P2414H CN-036WJX-74261-58V-EPDB ;
• 24” Dell P2414H CN-036WJX-74261-58V-EPNB ;
• claviers USB : 11 ;
• souris optique USB : 10 ;
• TP-Link TL-SG1016D ;
• câbles RJ45 standards : 11 ;
• câbles RJ45 jaune : 1 ;
• câbles RJ45 bleu : 3 ;
• câbles RJ45 vert : 3 ;
• câbles RJ45 rouge : 1 ;
• câbles VGA : 9 ;
• câbles DVI : 3 ;
• câbles DisplayPort : 13 ;
• multiprises X5 : 1 ;
• Multiprises X3 : 2 ;
• rallonge électrique : 2 ;
• multiprises X6 : 4.

• 1 tableau blanc Nautile sur pieds ;
• 2 tableaux blancs fixes ;
• 2 grands tableaux en liège.

La mise en place de règles de programmation permet d’établir des conventions permettant d’assurer la cohérence et la lisibilité du code produit.

TODO

TODO: Fiche Bilan Projet.png