QCM : Pilotage des projets informatiques (23 questions)

Explication

Un projet est un processus organisé qui vise à bâtir une réponse à un besoin. Le besoin lui-même, les activités courantes et sa simple description ne définissent pas le projet.

Explication

La définition ISO 10006 associe l’unicité du processus, des activités coordonnées et maîtrisées, des dates de début et de fin, un objectif et des contraintes. Les activités récurrentes, l’absence d’objectif précis ou l’omission des contraintes contredisent cette définition.

Explication

La triple contrainte associe le périmètre par rapport à l’objectif initial, le délai et le budget, lequel peut être exprimé en jours-hommes et en unités monétaires. Les ressources, les risques ou la qualité ne remplacent pas ces trois éléments.

Explication

L’expression des besoins décrit ce que le projet doit satisfaire et fixe son périmètre, ses exclusions et son contexte réglementaire. Les échéances, les interfaces et le stockage sont d’autres éléments à préciser, mais ne constituent pas l’aspect visé ici.

Explication

L’expression des besoins précise les échéances de mise en production par des dates précises et décrit exhaustivement les fonctions de l’application ou de l’outil. Le contexte réglementaire, les interfaces et les données statistiques sont des dimensions distinctes.

Explication

Le cahier des charges fonctionnel transforme les besoins en exigences que l’application devra respecter. Les choix techniques relèvent d’un autre niveau de conception, les tests de la recette et l’écriture du code du développement.

Explication

Les spécifications fonctionnelles détaillées précisent en langage littéraire l’enchaînement et le contenu des programmes, sans constituer leur implémentation. Le code correspond au développement, l’expression des besoins précède le cahier des charges et le cahier de recette décrit les tests.

Explication

La recette consiste à tester formellement le produit développé pour vérifier sa conformité au cahier des charges fonctionnel. Le cahier des charges définit les fonctions attendues, tandis que le développement écrit les programmes et les spécifications en détaillent le fonctionnement.

Explication

La recette de non-régression vérifie qu’une modification n’a pas dégradé les traitements existants. La recette unitaire teste les programmes individuellement, tandis que la recette d’intégration porte sur toute la chaîne informatique.

Explication

La recette se déroule dans un environnement distinct de la production, avec un échantillon pertinent couvrant des cas standards, non standards, limites et à données manquantes, puis des tests de volumétrie et de délais. L’environnement de production n’est pas l’environnement de test, et omettre les cas ou la volumétrie réduit la couverture.

Explication

Une anomalie bloquante doit être résolue avant la mise en production; seules les anomalies non bloquantes peuvent être corrigées dans un lot ultérieur. La traiter comme reportable confond les deux catégories, et la mise en production ne doit pas précéder sa résolution.

Explication

La décision de mise en production dépend des résultats de la recette consignés dans ses procès-verbaux ; une anomalie bloquante empêche de donner le feu vert. Le GO correspond à l’autorisation, le calendrier ne remplace pas la recette et une anomalie bloquante ne se traite pas comme une anomalie différable.

Explication

Le parallel run fait fonctionner les deux applications en même temps afin de comparer leurs résultats, au prix d’un dispositif coûteux et chronophage. Le big bang arrête l’ancienne application, le site pilote désigne une étape de déploiement et non un mode de comparaison simultanée.

Explication

Après une mise en production ou un déploiement de version, il faut vérifier dans le temps que l’application fonctionne correctement et que ses résultats restent cohérents. Une recette ponctuelle, la recherche limitée aux anomalies bloquantes ou la formation ne remplacent pas cette surveillance continue.

Explication

La maintenance applicative consiste à entretenir l’application pour qu’elle fonctionne correctement, y compris lors des montées de version de ses composants logiciels. L’ajout d’un besoin métier relève d’une évolution, tandis que la surveillance seule ou le remplacement ne définissent pas cet entretien.

Explication

Les nouveaux besoins applicatifs sont pris en compte au moyen d’évolutions. La maintenance concerne l’entretien de l’application, une anomalie correspond à un problème de fonctionnement et la surveillance ne crée pas la réponse fonctionnelle demandée.

Explication

En Agile, le développement est itératif, incrémental et adaptatif, et la conception comme la mise en production sont regroupées à chaque sprint. Le cycle d’étapes successives caractérise ici la confusion avec le cycle en V, tandis que la séparation des phases ou la réduction à la planification ne correspond pas à cette caractéristique.

Explication

Les sprints durent de deux à quatre semaines et font progresser le produit par itérations de prototypes opérationnels, afin de produire rapidement un MVP. Une version complète préalable, une spécification seule ou un cycle de plusieurs mois écartent cette progression incrémentale.

Explication

À la fin de chaque sprint, le prototype est testé et le retour de l’utilisateur final ou du product owner contribue à l’amélioration continue. Attendre la fin du projet reporte les tests, tandis que la validation technique seule ou l’absence de prise en compte des retours néglige cette boucle d’amélioration.

Explication

La conformité doit participer à l’équipe pluridisciplinaire dès le début et dialoguer de façon constructive pour que ses exigences soient prises en compte. Une intervention après livraison, une approbation finale isolée ou une transmission sans échange ne répond pas à cette règle.

Explication

Les exigences relatives au risque informatique figurent dans l’arrêté du 3 novembre 2014 modifié sur le contrôle interne, notamment aux articles 270-1 à 270-5. La notice de l’ACPR apporte des précisions, l’article 270-5 est une disposition de l’arrêté et la version initiale ne correspond pas à la référence indiquée.

Explication

L’article 270-5 prévoit un cadre clair et efficace pour conduire les projets et programmes, accompagné de processus couvrant l’acquisition, le développement, l’entretien et les changements des systèmes d’information. Limiter le dispositif aux changements ou omettre des processus clés ne satisfait pas cette portée.

Explication

L’article 270-5 prévoit que les modifications soient enregistrées, testées, évaluées, approuvées et implémentées de façon contrôlée. L’absence d’évaluation, le remplacement des tests par une approbation ou l’implémentation avant l’enregistrement omettent des contrôles requis.