Ce chapitre va rappeler les définitions du vocabulaire et des acronymes spécifiques à la gestion de projet et aux techniques informatiques afin d’avoir un référentiel commun accessible à tous. Ce référentiel doit vivre et être mis à jour pour les besoins contextuels UNIL et marché.
La référence lexicale générale est le dictionnaire de la langue française, C'est le dictionnaire qui fait fois pour les définitions et les significations des termes,. Par exemple [https://www.larousse.fr/](https://www.larousse.fr/) ou [https://www.dictionnaire-academie.fr/](https://www.dictionnaire-academie.fr/) Note: En sociologie, il est accepté que chaque contexte culturel puisse avoir sa propre perception et définition dite "sociale" d'un terme, donc que celle-ci puisse ne pas être alignée avec les valeurs du dictionnaire. En Français, une "définition sociale" ne peut pas être communément utilisée comme valeur de référence tant qu'elle n'est pas référencée dans un dictionnaire.
La terminologie SAP standard est déjà documentée en ligne, pour des raisons d’efficacité, nous gardons ce lien comme référence : [https://www.system-overload.org/sap/modules.html](https://www.system-overload.org/sap/modules.html) Les acronymes des titres et rôles sont disponibles dans la page associée: [Intervenants UNIL dans les projets](https://wiki.unil.ch/ci/books/methodologie-projets-mpro/page/annexe-2-intervenants-unil-dans-les-projets)| **Réf.** | **Acronyme** | **Signification** | **Définition** |
| 0 | **HERMES** | Méthode HERMES | [Méthode de gestion de projet](https://www.hermes.admin.ch/) suisse. Cette méthode est une copie partielle de la méthode anglaise Prince2. Hermès est principalement utilisé dans les organisations étatiques Suisse. |
| 1 | **SDP, OTP ou WBS** | organigramme des tâches du projet ou Work Breakdown Structure | En français, un WBS est la « Structure de répartition du travail ». C’est un organigramme des activités du projet trié par thèmes et/ou départements. La méthode Hermès définis plusieurs [scénarios standards](https://www.hermes.admin.ch/fr/pjm-2022/comprendre/scenarios.html) qui sont des WBS séquencés. |
| 2 | **Planning VS Schedule (EN)** | Plan(nification) VS Planning (FR) | En Français, le « Planning » (organisation/emploi du temps) et le « Schedule » (calendrier/planning) sont le même mot : « planning ». **Définitions françaises du mot **[**Planning**](https://www.larousse.fr/dictionnaires/francais/planning/61415#:~:text=1.,du%20temps%2C%20programme%20de%20travail.) **:** · Organisation d'un plan de travail, emploi du temps, programme de travail. · Dans une entreprise, une administration, service chargé d'ordonnancer et de lancer un travail. · Tableau représentant la prévision d'emploi d'un ensemble de personnels ou de machines. **Les différences de signification :** · Le « **Planning** », ou **Plan(ning)**, répond aux questions « quoi ? » et « comment ? ». Des livrables possibles sont un scénario Hermès, un diagramme BPMN des activités du projet ou un diagramme de PERT construit sur la base du WBS · Le « **Schedule** », ou **Planning**, répond aux questions « qui ? » et « quand ? » Des livrables possibles sont un plan d’action ou un diagramme de GANTT construit sur la base du « Planning » avec les estimations des durées des tâches.  |
| 3 | **KPI** | Key Process Indicator | Un KPI, ou indicateur de processus clef, est une valeur définie permettant de mesurer une performance et de suivre son évolution dans le temps. Par exemple, l’agilité SCRUM utilisera les points poker assignés aux sujets du Sprint pour mesurer la performance d’une période de réalisation. |
| 4 | **ROI** | Return on Investment | Le ROI, retour sur investissement en français, est la valeur attendue des résultats d’un projet. C’est une notion financière qui se veut être calculable. [Définition de ROI d’une source Web ](https://www.l-expert-comptable.com/a/52676-le-retour-sur-investissement.html): « La formule générale du **retour sur investissement** est : (gains – coûts de l’investissement) / coûts de l’investissement. La **durée de rentabilité** est le temps nécessaire pour que la mise de départ puisse être récupérée (retour sur investissement égal à zéro). » Dans les faits, le ROI n’est pas toujours calculable directement car certains gains ne sont pas facilement mesurables. Certaines données détaillées ne sont pas (encore) récoltées voir non récoltables. Par exemple : · - Un gain de qualité du logiciel amenant moins de demandes de modification des utilisateurs ; · - Un gain de qualité avec du monitoring assurant une proactivité à maintenir les sites en ligne ; · - Une nouvelle interface graphique plus intuitive réduisant le nombre de demandes de support ; · - Une meilleur communication grâce à un alignement faisant gagner du temps lors des diverses séances ; · - Une page web qui charge plus vite ou une structure des données plus intuitive afin de conserver l’attention des utilisateurs ; - Ou simplement que la perception de différentes personnes permet de ne pas percevoir de ROI sur certains sujets comme la qualité. **Ce ROI est défini par le demandeur dans la fiche DESI décrivant la demande de projet sous l’appellation « Valeur ajoutée ».** Pour les cas non mesurables, il faut trouver un autre KPI afin de mesurer le gain ou la différence avant la livraison. |
| 5 | **CSF** | Critical Success Factors | Les CSF, facteurs critiques de succès, sont les besoins « minimaux » attendu par le demandeur. Ils constituent le cahier des charges minimum. |
| 6 | **MVS** | Minimum Viable Solution | Une solution minimale viable est la solution la plus simple (et la moins coûteuse) qui contient néanmoins tous les composants de base identifiés comme nécessaires et peut donc être pilotée efficacement. C’est l’appellation logicielle d’un MVP. |
| 7 | **MVP** | Minimum Viable Product | Le MVP est le produit viable minimum. En termes de réalisation, cela signifie que les fonctions minimums à rendre le produit viable sont livrées. Cette notion est clef car elle permet une organisation itérative dans les projets et les maintenances. L’organisation itérative permet de livrer le plus rapidement possible une valeur ajoutée aux utilisateurs. Le MVP est très rarement un « produit final ». Le plus souvent, c’est le produit remplissant uniquement les CSF de la demande initiale ainsi que les contraintes annexes comme la sécurité. Pour donner un exemple plus concret et visuel, le MVP d’une voiture correspond à l’intégrations des pièces du châssis, des roues et du moteurs permettant aux véhicules de fonctionner techniquement selon la demande initiale. Pour autant, ce produit ne peut pas être commercialisé car il ne répond pas aux contraintes additionnelles comme les législations en place par exemple. Pour un logiciel informatique, le MVP serait le site et les fonctions métiers du site. Certaines fonctions de sécurité et d’intégration dans le Système d’information sont à ce stade encore manquant. Le MVP se différencie d’un PoC étant donné que sa réponse est pleine et entières vis-à-vis des critères minimaux de bon fonctionnement. |
| 8 | **DoR** | Definition of Ready | Le DoR, définition de prêt (à réaliser), est une liste de vérification des besoins nécessaires à commencer une tâche. Cela assure de ne pas démarrer sans les conditions nécessaires à la réalisation d’une tâche ou activité. |
| 9 | **DoD** | Definition of Done | Le DoD, définition de fait (ou réalisé), est une liste de vérification des CSF ou résultats attendus de l’activité. Cela permet d’assurer que l’activité a été réalisée sans oublier de détails importants à la qualité de la livraison. |
| 10 | **BDD** | Business Driven Development | Le BDD, développement orienté métier, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins du métier. L’approche Hermès assigne le métier au rôle de mandant afin d’assurer la satisfaction du métier ; Hermès est donc aligné avec le BDD. |
| 11 | **TDD** | Test Driven Development | Le TDD, développement orienté tests, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins de qualité du livrable en définissant non pas des spécifications métiers mais directement les cas de tests des résultats attendus.
Le TDD est totalement compatible avec le BDD. Le TDD permet d’optimiser la charge administrative de la gestion de projet en orientant les spécifications vers la validation des livrables par des tests. **Optimisation :** *Des spécifications métiers de grande qualité vont définir les attentes en incluant les informations de vérifications de ces attentes avec des cas de tests ou des DoD*. |
| 12 | **DDD** | Domain-Driven Design | Le DDD, conception pilotée ou orientée par le domaine en français, est une technique de conception de logiciel que l’on peut résumer à architecturer la solution afin de représenter le métier et ses processus plutôt que de coder les fonctions du métier dans un bloc. C’est une forme de modularité qui nécessite une architecture technique. |
| 13 | **QA** | Quality Assurance | Le QA, assurance qualité, est une notion pour englober l’ensemble des efforts à faire pour assurer la qualité d’un produit ou d’un service : tests, DoD, monitoring ou tout autre mesure. Dans un projet Hermès, le QA se limite aux vérifications de qualité (QC) définis dans le projet, par exemple sur la base des CSF ou des attentes définies par des contraintes extérieures ou internes au projet, du point du vue d’un chef de projet. Un rôle de Gestionnaire de la qualité et des risques a la charge de la qualité transverse du projet. Pour avoir plus de détails, voir le concept de plan de qualité. |
| 14 | **Sprint** | Un Sprint est une unité de temps de réalisation qui se situe entre 1 et 4 semaines. Cette unité soutient la notion de réalisation itérative tout en permettant un contrôle régulier des niveaux d’avancement dans les tâches à faire.
Les équipes de développement en interne utilisent des Sprints d’une valeur de 2 semaines. Le pôle projet en interne utilise des Sprints d’une valeur de 1 semaine. | |
| 15 | **RAM (RASCI et RACI ou DACI)** | Responsibility Assignment Matrix | Le RAM (Responsibility Assignment Matrix) est une matrice d’assignation des rôles et responsabilité de chacun
Le RAM est le nom général. Les nom, RASCI et RACI, sont les noms issus des rôles assignés :
Il est envisageable d’enrichir cette matrice avec d’autres rôles à préciser. La matrice DACI propose une autre organisation comparable mais moins « populaire/usité » :  Pour la comparaison : · Driver = Responsible · Approver = Accountable · Contributor = Support & Consulted · Informed = Informed |
| 16 | **SPOC** | Single Point of Contact | Le SPOC est le point d’entrée des communications et demandes selon le contexte. C’est l’entité à charge de trier, filtrer et rediriger les sujets aux bonnes personnes. Le PMO est le SPOC pour les demandes de nouveaux projets. |
| 17 | **PLM** | Product Lifecycle Management | La gestion du cycle de vie d’un produit est un cycle en boucle fermé pour la gestion d’un produit. Il part de l’idée en passant par sa conception, sa réalisation, sa mise en service, son support et sa retraite (ou remplacement) qui retombe ensuite sur l’idée. Cette approche intègre la maintenance et le support nécessaire à l’exploitation de la solution à l’inverse du projet qui lui livre des informations à cette phase de maintenance sans être une partie prenante active au bon fonctionnement de cette phase cruciale qui correspond au début de la vérification du ROI du produit réalisé pendant le projet. |
| 18 | **UaT** | User at Test | La notion d’UAT signifie qu’aucun produit ne peut être considéré comme validé tant que les utilisateurs finaux n’ont pas fait eux-mêmes les tests d’acceptation du produit et validé par eux même. Le rôle des testeurs est donc d’assurer la qualité du produit avant le passage du métier afin de garder des coûts de qualité maitrisés par l’entité. |
| 19 | **PBS** | Product Breakdown Structure | En français un PBS est la « Structure de répartition (des fonctions) du produit ». C’est un organigramme des fonctions du produit trié par thèmes et/ou modules. C’est comparable à un WBS mais sur une vue du produit ou service. |
| 20 | **ITSM** | Information Technology Service Management | L’ITSM, la gestion du service IT, représente les bonnes pratiques de gestion d’un département IT. La méthodologie ITIL décrit ces bonnes pratiques en s’orientant sur la maintenance, la qualité du service et l’intégration des projets. ISO-9001 :2015 propose une vue compatible incluant les projets. |
| 21 | **ITIL** | Information Technology Infrastructure Library | ITIL est un ensemble de bonnes pratiques conçues pour aider une organisation à tirer une valeur optimale de l'informatique (projets, maintenances et opérations) en alignant les services informatiques sur la stratégie métier. |
| 22 | **DRP** | Disaster Recovery Plan | Le DRP, ou plan de secours en français, est le plan de gestion mis en place en cas désastre. Ce plan peut posséder plusieurs scénarii comme la méthodologie HERMES. |
| 23 | **BCP** | Business Continuity Plan | Le BCP, ou plan de continuité métier ou des opérations, est le plan de secours utilisé en cas d’évènements non planifiés impactant les services aux utilisateurs finaux. |
| 24 | **SWOT** | Strength, Weakness, Opportunity & Threat | Le SWOT est une matrice d’analyse des risques classant les risques selon leurs impacts comme le nom de la méthode le donne : force, faiblesse, opportunités, menaces. |
| 25 | **MoSCoW** | [Must, Should, Could & Would](https://everlaab.com/8-methodes-de-priorisation-simples-pour-mieux-gerer-votre-quotidien/#:~:text=Elle%20consiste%20%C3%A0%20organiser%20vos,trait%C3%A9e%20le%20plus%20rapidement%20possible.) | La méthode de MoSCoW est une méthode de priorisation selon l’importance : · Must : doit être · Should: devrait être · Could: pourrait être · Would: ne sera pas |
| 26 | **KISS** | Keep, Improve, Start & Stop | La méthode KISS permet de prioriser les sujets selon les critères : garder, améliorer, démarrer ou arrêter.
La matrice KISS est très proche d’une matrice MoSCoW. |
| 27 | **KISS!** | Keep It Simple, Stupid! | Le principe de KISS! Est de garder les choses assez simples pour : · Que tout le monde ait accès à l’information (documentation) · Que les sujets soient facilement maintenables (développement) o Eviter de produire de gros blocs logiciels ayant une sur-inflation de fonctionnalités qui pourraient être plusieurs solutions o Eviter de produire des solutions dont seul quelques élus pourront faire la maintenance |
| 28 | **CRUDE** | Create, Update & Delete | Un CRUDE est un terme technique signifiant que des opérations sont faites sur les données en base de données. C’est un terme le plus souvent utilisé en BA ou en QA pour définir l’action à développer ou à tester. |
| 29 | **BDD ou DB** | Base de données ou Data Base en anglais | Lieu de stockage des données dans un format technique utilisé par les applications. |
| 30 | **CMS** | Content Management System | Un gestionnaire de contenu permet de pouvoir facilement créer, éditer, collaborer et publier du contenu digital. |
| 31 | **ERP** | Enterprise Resources Planning | Un ERP est un applicatif qui permet de suivre et automatiser les processus de l’entreprise. Pour la gestion de projet, Orchestra est qualifiable d’ERP. |
| 32 | **Baseline ** | Ligne de base | Cette ligne est une représentation des contraintes initiales du projet (plan et planning) servant de référence afin de pouvoir adapter le pilotage du projet et de rester dans les plans tels que définis, tout en vérifiant que le projet reste dans les marges définies selon son avancement. |
| 33 | **RT(F)M** | Read The (Fucking) Manuel | Initialement c’est une boutade de développeur, mais le terme se généralise facilement dans des équipes CI quand les sujets sont bien documentés. |
| 34 | **Kanban** | Tableau de suivi | C’est une manière de suivre les activités d’un WBS ainsi que leur statut. Ces activités sont découpées selon leur niveau : · Epic : c’est le niveau le plus haut. Il peut contenir tous les types de cartes. Il est conseiller de ne pas y imbriquer trop d’autres Epics selon le principe KISS ! · User Story : C’est le niveau qui décrit les cas d’utilisations, cela correspond au diagramme UML « Use-Case ». Une user Story ne devrait contenir que des Features et des Tasks · Feature: C’est la fonction à réaliser, elle peut contenir des Tasks. · Task: C’est une action simple à réaliser comme par exemple préparer une base de données. |
| 35 | **Backlog** | Liste des tâches | **Une liste ordonnée et hiérarchisée** des caractéristiques du produit souhaitées par le client et les missions à réaliser par l’équipe. |
| 36 | **Burn Up/Down chart(s)** | Diagrammes de consommation | Ce sont 2 représentations de la charge de travail : consommée (Down) par l’équipe ou à consommer (Up) sur le Sprint |
| 37 | **Release** | Version | Une Release est une nouvelle version du logiciel apportant ses corrections, modifications ou améliorations. |
| 38 | **SIPD** | Sûreté de l'information et protection des données | Ce concept vient de la [méthodologie Hermès](https://www.hermes.admin.ch/fr/gestion-du-projet/comprendre/resultats/concept-sipd.html). Il reprend les notions de DRP voir BCP (CISO UNIL) tout en y intégrant les notions de sécurité.
Cette approche groupée reste difficile à appréhendez pour les novices en matières d’ITSM. |
| 39 | **Agile** | # Méthode agile | L’agilité est une approche d’organisation d’une équipe de développement centrée sur l'humain et la communication. Ce qui signifie que cette méthodologie possède une dépendance clef à l’application de ses valeurs.
Beaucoup des pères fondateurs ont renié le manifeste agile du fait des travers liés aux manques d’applications des valeurs dans les entités. |
| 40 | **Pjt** | Projet | Un projet est un « one-off » qui possède un début et une fin.
Il est unique.
Sur deux projets similaires en tout, le 2e est un processus.
Dans le cas de différences, le 2e est une variante donc un projet.
Les scénario Hermès sont des tentatives de conversion de projet « similaires » en processus. Or selon les caractérisations Hermès actuelles, ou les définitions internes, ces scénarios sont au mieux des optimisations pour la gestion de projet. Une optimisation efficace marché est de transformer l’ITSM afin d’avoir les processus nécessaires pour la partie « Run », et de la compléter des cas d’usages de « Build ». Le traitement de la demande suit un processus, la réalisation de la demande elle suit un mode de gestion de projet adapté (Scénario Mission par exemple). |
| 41 | **Pcs** | Processus | Un processus est une activité répétitive qui est documentée et facile à reproduite et enseigner. Un processus doit pouvoir faire référence au terme « RTFM ». |
| 42 | **QC** | Quality Control | Le contrôle qualité est la partie réalisation du QA. Il est donc théoriquement impossible de faire un QC « de qualité » sans avoir fait un QA.
Le concept de test générique est un QA pour un scénario du type « de développement IT » dans Hermès. |
| 43 | **MTBF** | Mean Time Between Failure | « MTBF est le temps écoulé prévu entre les pannes inhérentes d'un système mécanique ou électronique pendant le fonctionnement normal du système. Le MTBF peut être calculé comme la moyenne arithmétique (moyenne) du temps entre les pannes d'un système. Le terme est utilisé pour les systèmes réparables, tandis que le temps moyen jusqu'à panne (MTTF) désigne le temps prévu jusqu'à panne pour un système non réparable. » (Source [Wiki](https://en.wikipedia.org/wiki/Mean_time_between_failures)) |
| 44 | **MTTR (1)** | Mean Time To Recovery Repair | « Le temps moyen de réparation (MTTR (1)) est une mesure de base de la maintenabilité des éléments réparables. Il représente le temps moyen nécessaire pour réparer un composant ou un appareil défaillant. » (Source [Wiki](https://en.wikipedia.org/wiki/Mean_time_to_repair)) |
| 45 | **MTTR (2)** | Mean Time To Recovery | « Le temps moyen de récupération (MTTR (2)) est le temps moyen qu'il faudra à un appareil » ou service « pour se remettre d'une panne. Les exemples de tels dispositifs vont des fusibles à réarmement automatique (dont le MTTR serait très court, probablement quelques secondes), à des systèmes entiers qui doivent être réparés ou remplacés. » comme des applications informatiques (Source [Wiki](https://en.wikipedia.org/wiki/Mean_time_to_recovery)) |
| 46 | **6 s** | **Six Sigma** | « 6 Sigma est une marque déposée de Motorola désignant une méthode structurée de management visant à une amélioration de la qualité et de l'efficacité des processus » (Source [Wiki](https://fr.wikipedia.org/wiki/Six_Sigma)) |
| 47 | **DPRO** | Directive Projet | La DPRO est pilotée par la PMO et formalisée à l’aide des directives CI-UNIL. La DPRO formalise l’utilisation [d’Hermès](https://www.hermes.admin.ch/fr/pjm-2022/comprendre.html) comme méthode de projet. |
| 48 | **MPRO** | Méthode projet | La MPRO est pilotée par l’équipe DSM-PRO, dans le respect de la DPRO, avec comme objectifs principaux d’augmenter la qualité dans la gestion de projet et de réduire les investissements temporels des chefs de projets dans des tâches répétitives par la mise en place et utilisation de standards de gestion communs. Hermès utilise la notion de scénarii pour trier ces standardisations pour les projets.
La MPRO peut aussi être améliorer par le biais de standards plus orientés pour les besoins de l’organisation permanente ; par exemple la manière de mettre en place ou de communiquer avec les outils des projets. |
| 49 | **PoC ou POC** | Proof of Concept | Le PoC, « preuve de concept » traduit, ou en français un « prototype », est la maquette permettant de vérifier la viabilité d’une demande. Cette notion permet de découvrir les difficultés, possibilités ou limitations techniques liées à une idée. En informatique, la maquette réalisée sera peu fonctionnelle mais permettra aux équipes de valider la capacité de réalisation et le rendu final à moindre coût que le projet partiel voir entier. |
| 50 | **EPT, ETP ou FTE** | Equivalent Temps Plein ou Full Time Equivalent | Cette notion correspond à une charge de travail à 100% selon les normes contractuelles du Fort défini. Pour l’UNIL c’est le Canton de Vaud avec 42h par semaine comme ETP. |
| 51 | **BPM(N)** | Business Process Model (and Notation) | C'est-à-dire « modèle de procédé d'affaire et notation », est une méthode de [modélisation](https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_de_processus) de [processus d'affaires](https://fr.wikipedia.org/wiki/Processus_d%27affaires) pour décrire les chaînes de valeur et les activités métier d'une organisation sous forme d'une représentation graphique |
| 52 | **PM** | Project Management | Management de Projet |
| 53 | **PV** | Procès-Verbal | Le compte rendu officiel de la séance est appelé PV. |
| 54 | **SI ou IS** | Système d’information ou Information System | Cette notion défini l’ensemble des produits et services nécessaires à la gestion des informations. De nos jours, cela représente la liste des biens et services gérer et fourni par le CI à ses utilisateurs. |
| 55 | **URL** | Uniform Resource Locator | Adresse Web (ex. [https://www.unil.ch](https://www.unil.ch)) |
| 56 | **N/A** | Not Applicable | Cette notion est utilisée dans la documentation pour qualifier l’inutilité d’un sujet. |
| 57 | **O(S)FA** | One (Size) Fits All | C’est une notion d’industrialisation disant qu’un seul produit ou service peut répondre aux besoins de tous. |
| 58 | **DMS ou GED** | Document Management System ou Gestion Electronique de Document | Un DMS, ou une GED, est un système informatique proposant un ensemble de fonctions liées à la gestion des documents. De manières non exhaustive, les principales fonctions sont : · Gestion des versions · Processus de validation d’un document · Processus de publication d’un document |
| 59 | **IHM** | Interface Homme (ou Humain) Machine | L’IHM est l’ensemble des composant visuels ou autre qui permettent l’interaction entre l’utilisateur et la machine (PC) |
| 60 | **PC** | Personal computer | En français, c’est un ordinateur. |
| 61 | **OS** | Operating System | L’OS est l’ensemble des composants logiciels permettant l’interaction avec l’ordinateur. Les OS connus sont : Windows, MacOS, Android |
| 62 | **PjtS** | Projet (simple) | Voir la définition d’un projet (Ref 41) pour le côté général. Un projet simple est un projet dont les liens entre les activités / tâches est de nature simple : - Fin-début - Début-début - Fin-Fin - Début-fin |
| 63 | **PjtC** | Projet (Complexe) | Voir la définition d’un projet (Ref 41) pour le côté général et d’un projet simple (Ref 63) pour les cas simples.
Un projet complexe est un projet dont les liens entre les activités est de nature complexe :
- Dépendances nécessaires entre les tâches en cours de réalisation
Dans le cas où ces liens fort n'existent que de manière sporadique, nous parlons d’un projet simple. |
| 64 | **Pg** | Programme (pour les projets) | Un [programme](https://www.hermes.admin.ch/fr/pgm-2022/comprendre/apercu-de-la-gestion-de-programme.html) est un projet constitué de plusieurs projets. Voir la définition d’un projet (Ref 41) pour le côté général. |
| 65 | **PgS** | Programme (simple) | Voir la définition d’un programme (Ref 65) pour le côté général et d’un projet simple (Ref 63) pour les cas simples. La définition du programme simple est celle d’un projet simple où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme. Un programme simple est un projet dont les liens entre les sous-projets est de nature simple : · Fin-début · Début-début · Fin-Fin · Début-fin |
| 66 | **PgC** | Programme (Complexe) | Voir la définition d’un programme (Ref 65) pour le côté général et d’un programme simple (Ref 64) pour les cas simples.
La définition du programme complexe est celle d’un projet complexe où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme.
Un programme complexe est un projet dont les liens entre les sous-projets est de nature complexe :
· Dépendances nécessaires entre les sous-projets en cours de réalisation
· Ces dépendances peuvent être entre des de nature simple entre les activités / tâches des sous-projets
Ces dépendances peuvent être matérialisées avec des dépendances entre des releases des sous-projets par exemple. |
| 67 | **PDS** | Point De Situation | C’est une séance pour faire l’état de l’art, entre plusieurs acteurs, de l’évolution d’une situation |
| 68 | **SAP ACTIVATE** | C’est la méthodologie de projet de SAP | |
| 69 | **BP (SAP)** | Business Partner | C’est une notion de base de SAP. Toutes les actions SAP sont liées à des BP qui endossent un rôle dans les processus financiers. |
| 69 bis | **BP (générique)** | Best Practice | L’ensemble des expériences faites et documentées au format d’un processus.
Dans SAP, c’est implémenté au travers d’un scope item. |
| 70 | **HANA ** | High performance ANalytic Applicance | Une « Appliance » de SAP, une combinaison hardware et software, optimisée pour tirer parti des technologies les plus récentes en matière de processeurs multicœurs et de mémoire vive. |
| 71 | **ECC ** | ERP Central Component | Version de SAP actuelle basée sur le système SAP R/3. |
| 72 | **PSM-FM ** | Public Sector Management - Funds Management | Module SAP de gestion des processus budgétaires et de l’exécution budgétaire dans S/4HANA faisant partie de l’industrie secteur public. |
| 73 | **PS ** | Project System | Module SAP concernant la gestion des projets dans SAP ; il permet d'effectuer les actions fonctionnelles suivantes : Structuration des projets. Suivi de coûts et budgets. Planning et calendrier. |
| 74 | **EC-PCA ** | Entreprise Controlling - Profit Center Accounting | Module SAP de la Comptabilité des Centres de Profits. |
| 75 | **HCM ** | Human Capital Management | Module et ensemble de solution SAP couvrant les processus HR dans les solutions ECC et S/4 comme l’administration HR, le traitement des salaires, la gestion des temps et absences, etc. |
| 76 | **LoB ** | Line of Business | Regroupement de fonctionnalités proposé par SAP dans S/4HANA afin de couvrir une famille de processus ou un domaine d’entreprise. |
| 77 | **SAC ** | SAP Analytics Cloud | Solution cloud proposée par SAP pour gérer les processus de planification budgétaire et le reporting |
| 78 | **WRICEF ** | Workflow Reporting Interface Conversion Enhancement Form | Correspond à la typologie du développement envisagé dans un domaine : - Workflow (processus et étapes d’acceptation, validation) - Reporting (tous éléments de restitution) - Interface (scénario d’intégration avec d’autres applicatifs comme SYLVIA p.ex.) - Conversion (tout programme effectuer dans le cadre des reprises de données) - Enhancement (programme couvrant une fonctionnalité particulière non standard) - Form (formulaire, ou tout document/correspondance devant être généré et imprimé depuis SAP |
| 79 | **SCI** | Système de Contrôle Interne | |
| 80 | **SAP** | Systems, Applications and Products | Par abus de langage le nom utilisé pour désigner un [progiciel de gestion intégré](https://fr.wikipedia.org/wiki/Progiciel_de_gestion_int%C3%A9gr%C3%A9 "Progiciel de gestion intégré") développé et commercialisé par l'éditeur de ce produit ([SAP AG](https://fr.wikipedia.org/wiki/SAP_(entreprise) "SAP (entreprise)")) |
| 81 | **LPD** | Loi sur la protection des données | Loi Suisse |
| 82 | **nLPD** | Nouvelle Loi sur la protection des données | Mise à jour de la Loi Suisse |
| 83 | **CCP** | Comité de coordination des projets | Organisation de projet |
| 84 | **Ci** | Centre Informatique UNIL | Organisation Permanente |
| 85 | **DESI** | Demande d’Evolution du Système d’Information | Document initial pour la demande de création du projet |
| 86 | **DEV-INT** | Pôle Développement et Intégration | |
| 87 | **DSM** | Division des développements des Solutions Métiers | |
| 88 | **FRAT** | Fiche de Registre des Activités de Traitement | |
| 89 | **MPRO** | Méthodologie Projets | Organisation de projet |
| 90 | **OJ** | Ordre du Jour | |
| 91 | **PAT** | Personnel Administratif & Technique | Le personnel UNIL qui ne fait pas parti du corps enseignant |
| 92 | **PPRO** | Pôle Projets | |
| 93 | **RGPD** | Règlement Général sur la Protection des Données | |
| 94 | **SI ACAD** | Système d’Information Académique | |
| 95 | **SI UNIL** | Système d’information de l’UNIL | |
| 96 | **TransNum** | Initiative Transition numérique | |
| 97 | **UNIL** | Université de Lausanne | |
| 98 | **DCSR** | Division calcul et soutien à la recherche | |
| 99 | **RDP** | Revue de projets | |
| 100 | **PDI** | Plan directeur informatique | |
| 101 | **SDM** | Schéma directeur métier | |
| 102 | **RGE** | Règlement Général des études | |
| 103 | **SLCM** | Student Life Cycle Management | |
| 104 | **BaS ou SBX** | Bac à Sable ou SandBoX | C'est un environnement technique de notre plateforme SAP qui tient principalement un rôle d'un environnement de post-production pour des raisons de sécurité, mais au besoin, il peut tenir un rôle de pré-production pour tester les paquets de release à déployer ou de test de dev pour régler des conflits de version des composants SAP |
| 105 | ** SPO** | C'est une procédure de gestion des versions de SAP qui inclus une analyse d'impacts et d'autres standards de qualité. | |
| 106 | **Grooming** | ||
| 107 | **Sprint Planning** | Séance de planning pour les activités qui seront réalisées pendant la durée du Sprint | |
| 108 | **Sprint Review ** | Séance de revue des activités réellement réalisées pendant la durée du Sprint | |
| 109 | **(Daily) SuM** | **(Daily) Stand-up Meeting** | Séance de suivi (quotidienne), de la méthode Agile SCRUM, qui selon la méthodologie se passe debout afin de forcer les participants à aller à l'essentiel. le plus vite possible |
| 110 | **Sprint Retrospective ** | Séance d'analyse afin de pouvoir tirer les expériences sur la période de temps écoulée, cette séance liste le bon, le moins bon et les actions d'amélioration à mettre en place | |
| 111 | **Backlog Review / Refinement** | C'est une activité, qui peut se faire dans une séance, de revue et priorisation des sujets ouverts du Backlog. | |
| 112 | **DoS** | Definition of Small | La définition de petit est une notion qui adapte le périmètre de l'activité à la période de temps allouée pour sa réalisation, ou Sprint. |
| 113 | **Agile SCRUM** | C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'une équipe de développement pour un backlog | |
| 114 | **Agile SAFe** | Scaled Agile Framework | C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'un portefeuille de projet |
| 115 | **Lean** | Lean est l'une des méthodologies de gestion, notamment pour les projets. C'est la méthodologie mère des différentes méthodologie Agiles. | |
| 116 | **IceBox** | "la boite à glaçon", c'est un terme anglais américain signifiant "en attente".
C'est la seule exception de traduction qui sera traité dans cette liste. | |
| 117 | **HPC** | High Performance Computing | Le calcul haute performance (HPC) **permet de traiter les données et d'effectuer des calculs complexes à des vitesses élevées.** |
| 118 | **Dev Full-stack** | "Un développeur Full Stack est quelqu'un de familier avec toute la stack technique et qui a les compétences pour faciliter le travail de ses collaborateurs".
Cela signifie réellement que le développeur connait les technologies avec lesquels il travaille et ne représente pas une surcharge pour ses collaborateurs techniques. En Français, ces acteurs portent le nom d'architectes voir de directeurs techniques. | |
| 119 | **SRE** | Site Reliability Engineering | La SRE est la mise en œuvre pratique de DevOps |
| 120 | **DevOps** | Development & Operations | "DevOps **repose sur une culture de la collaboration entre développeurs et équipes opérationnelles, qui partagent les responsabilités et combinent le travail**. Il améliore l'efficacité des équipes et permet d'accélérer les transferts de tâches et la création de code conçu pour un environnement d'exécution spécifique." |
| 121 | ** ** | [Matrice d'Eisenhower](https://everlaab.com/8-methodes-de-priorisation-simples-pour-mieux-gerer-votre-quotidien/#:~:text=Elle%20consiste%20%C3%A0%20organiser%20vos,trait%C3%A9e%20le%20plus%20rapidement%20possible.) | Cette matrice est similaire aux méthodes MoSCoW & KISS, elle sert à la priorisation des activités selon des critères d'urgence et d'importance: - Une tâche est urgente quand celle-ci doit être traitée le plus rapidement possible. - Une tâche est importante quand celle-ci contribue à la réalisation de vos objectifs à court, moyen ou long terme. Ce qui nous donne la matrice de 2 par 2 suivante: - **Urgent et important** : Ce sont les tâches que vous devez traiter le plus rapidement possible. - **Important et non urgent** : Ce sont les tâches que vous planifiez dans votre calendrier - **Urgent mais non important** : Ce sont les tâches que vous déléguez - **Ni urgent ni important** : Ce sont les tâches que vous éliminez ou limitez |
| 122 | **ABCDE** | [Méthode ABCDE](https://everlaab.com/8-methodes-de-priorisation-simples-pour-mieux-gerer-votre-quotidien/#:~:text=Elle%20consiste%20%C3%A0%20organiser%20vos,trait%C3%A9e%20le%20plus%20rapidement%20possible.) | Cette méthode est similaire aux méthodes MoSCoW, KISS et à la matrice d’Eisenhower, les tâches sont triées sur la base de paramètre d'importance, optionnalités, délégation et élimination:
- **A = Les Tâches très importantes** : sont celles que vous devez absolument faire. Ne pas les faire peut avoir de graves conséquences.
- **B = Les Tâches importantes** : sont celles que vous devez faire, une fois que vous avez accompli les tâches très importantes. Ne pas les accomplir n’aura que des conséquences mineures.
- **C = Les Tâches optionnelles** : correspondent aux tâches que vous pouvez faire si et seulement si les tâches de la catégorie A et B sont terminées. Ne pas les faire, n’a pas vraiment de conséquences négatives.
- **D = Les Tâches à déléguer** : sont celles que vous transférez à d’autres personnes pour vous libérer du temps.
La délégation est un art comme d'autres sujet, il ne sera pas aborder dans cette liste. - **E = Les Tâches à éliminer** : sont toutes les tâches que vous devez éliminer de votre to-do list, soit parce qu’elles ne vous sont d’aucune utilité ou parce qu’elles ne sont plus pertinentes.Pour bien appliquer cette méthode, veillez à avoir relativement peu de tâches dans les catégories A et B en comparaison des catégories C, D et E. |
| 123 | **RICE** | [RICE Scoring](https://www.digilityx.com/post/3-methodes-de-priorisation-pour-etre-plus-efficace-dans-son-product-management) | Cette méthode est similaire aux autres mais sur la base des paramètres **R**each, **I**mpact, **C**onfidence et **E**ffort. - **Reach**: une estimation du nombre de personnes que votre initiative atteindra dans un laps de temps donné. C'est un paramètre centré sur les utilisateurs finaux. - **Impact:** la manière dont les personnes atteintes seront affectées en tant qu'individus. On défini cela sur une échelle: - 3 = impact massif - 2 = impact élevé - 1 = impact moyen - 0,5 = impact faible - 0,25 = impact minimal - **Confidence:** un indice de confiance en pourcentage que l'objectif est atteignable, idéalement sur des données d'expériences passées, sinon sur une sentiment de confiance. Supérieur à 80% est une confiance élevée alors qu'inférieur à 50% est un "moon shot", les priorités sont ailleurs. - **Effort:** C'est l'estimation de la charge de travail en jour homme; cela informe indirectement sur la complexité de la tâche. Le **Score** est alors calculé: **(Reach x Impact x Confidence) / Effort** |
| 124 | **Kano** | Kano Model | Ce modèle porte le nom de son créateur Noriaki Kano.
Ce modèle va permettre de trier les qualités des fonctionnalités (attractivité, proportionnalité et nécessité) sur 2 axes (satisfaction et présence de la fonction).
Afin de comprendre le modèle, il faut clarifier les définitions:
- **attractivité:** représente les caractéristiques que les clients/utilisateurs percevront comme allant au-delà de leurs attentes et étant différenciateurs des concurents.
- **proportionnalité:** classe les fonctionnalités qui, plus elles seront développées et abouties, plus elles généreront de la satisfaction
- **nécessité** (obligatoire): Représente sans surprise le minimum attendu par les clients pour résoudre leurs problèmes. Sans elles, le produit leur est pratiquement inutile.
Un tel modèle se comprends mieux dans sa représentation graphique:
[](https://wiki.unil.ch/ci/uploads/images/gallery/2024-05/0nvimage.png)
Et se prépare sur la base d'une liste de fonctions trié dans une matrice:
[](https://wiki.unil.ch/ci/uploads/images/gallery/2024-05/7ENimage.png)
Les autres méthodes sont plus faciles à l'utilisation. |
| 125 | **Priorisation** | [Priorisation ](https://www.larousse.fr/dictionnaires/francais/prioriser/)(des tâches) | L'action "d'Accorder une importance préférentielle à quelque chose ou à quelqu'un".
Il existe plusieurs moyen d'effectuer cette action. Cette liste référence des méthodes préférées de par leur aspects tangibles. Ce référencement est non exhaustif, une recherche google vous permettra d'en trouver d'autres. Les méthodes peuvent être adaptée ou combinée selon le besoin. Dans le cas d'un projet nécessitant une priorisation spécifique ou retravaillé depuis les méthodes, merci de vous référer au chef de projet qui lui même se réfèrera au PMO en cas de besoin. |
| 126 | **BaU** | "Business as Usual" | Signifie que l'activité est vue comme régulière et une tâche quotidienne qui ne nécessite plus de suivie spécifique comme au travers d'une gestion de projet par exemple. |
| 127 | **SLA** | Service Level Agreement | Le SLA est le niveau de service offert au client pour la gestion des incidents pouvant impacter le fonctionnement du service. Il fournit une partie des réponses contenues dans les plans BCP et DRP. |
| 128 | **GTI** | Garantie de Temps d’Intervention | C'est le temps de prise en compte de l'incident |
| 129 | **GTR** | Garantie de Temps de Rétablissement | C'est le temps nécessaire à la résolution de l'incident pour un retour au service normal |
| 130 | **PDMA** | Perte de Données Maximale Admissible | C'est en générale l'ensemble des données perdu depuis le dernier back-up. |
| 131 | **RPO** | Recovery Point Objective | C'est un point de mesure calculé du nombre de données perdu sur la période précédent l'incident |
| 132 | **RTO** | Recovery time objective | C'est le terme anglais pour le GTR. |
| 133 | **PMI** | Project Management Institute | c'est une entité spécialisé dans la gestion de projet qui propose divers certification et le PMBoK |
| 134 | **PMP** | Project Management Professional | c'est l'une des certification de PMI |
| 135 | **PMBoK** | Project Management Body of Knowledge | c'est le livre des connaissances de gestion de projet proposé par PMI |
| 136 | **BABoK** | Business Analysis Body of Knowledge | c'est le livre des connaissances d'analyse métier proposé par IIBA |
| 137 | **IIBA** | International Institue of Business Analysis | c'est une entité spécialisé dans la gestion de projet qui propose divers certification et le BABoK |
| 138 | **WIP** | Work in Progress | Travail en cours dans une colonne d'un board Kanban |
| 139 | **SMART** | *Specific, Measurable, Achievable, Realistic, Time-bound* | La méthode [SMART](https://fr.wikipedia.org/wiki/Objectifs_et_indicateurs_SMART) consiste à identifier des objectifs quantitatifs et/ou qualitatifs sur une période définie. |
| 140 | **CAPM** | Certified Associate in Project Management | c'est l'une des certification de PMI |
| 141 | **FYI** | For Your Information | Pour votre information |
| 142 | **FA** | For Action | Pour action |
| 143 | **Esprit d'équipe** | cohésion de groupe | C'est ce qui permet le proverbe "Teamwork is Dreamwork" signifiant "le travail en équipe est un travail de rêve". Avant tout, c'est un ensemble de savoir-être et de savoir-faire qui permettent d'instaurer la confiance, incluant le savoir gérer les différences et les crises. |
| ** ** | |||
| ** ** |