Analyser le besoin et le modéliser

2. La phrase 2 n’est pas mesurable : « lisible en plein soleil » ne dit pas comment vérifier. Réécriture possible : « les textes et les boutons ont un contraste d’au moins 4,5 pour 1 avec leur fond, et un test de saisie d’un contrôle sur la terrasse, en plein jour, est réussi par 3 techniciens sur 3 ».

1. Faux : «include» part du cas de base (« Gérer les plans préventifs », « Enregistrer un contrôle ») et pointe vers le cas inclus « Rechercher un équipement ».
2. Faux : c’est une extension («extend»), qui ne se déroule que si la condition est vraie (un point non conforme).
3. Vrai : le Responsable technique est une spécialisation de Technicien (triangle creux sur Technicien) ; il hérite de ses cas.
4. Faux : c’est le Planificateur qui déclenche la génération ; la Messagerie est un acteur secondaire, sollicitée pour notifier.
5. Vrai : le cas étendu est complet par lui-même ; l’extension n’ajoute un comportement que sous condition.

1. 0..1 du côté de Technicien : au plus un technicien, et aucun au minimum (intervention pas encore affectée).
2. Non : 1..* du côté de PointControle, un plan comprend au moins un point.
3. 0..* du côté d’Equipement : zéro, un ou plusieurs équipements.
4. Oui : 0..1 du côté d’InterventionPreventive dans l’association « déclenche » : une intervention peut n’être déclenchée par aucune intervention préventive (une panne signalée par la réception, par exemple).

3. Un nom en italique signalerait une classe abstraite, sans objets directs. Ici, Intervention est une classe concrète : on peut créer un objet Intervention qui n’est pas une intervention préventive ; il représente une intervention ordinaire, dite corrective (panne signalée par la réception, ou intervention créée par RG6 après un contrôle non conforme). Seule l’intervention préventive a une sous-classe, car elle seule ajoute des informations (échéance prévue, résultat).

4. Le losange plein est une composition : un point de contrôle fait partie d’un seul plan et n’existe pas sans lui. Supprimer le plan supprime ses points de contrôle.

2. Critères d’acceptation de R4 :

Scénario 1 — suspendre un plan Étant donné le plan « Climatisation de la salle de séminaire – semestriel » du Phare de Royan, actif, d’échéance le 13/11/2026, quand Franck Guillou (profil Responsable) le suspend le 2 novembre, alors le plan devient inactif et, lors de la génération du 9 novembre à 5 h, aucune intervention préventive n’est créée pour ce plan.

Scénario 2 — réactiver le plan Étant donné ce plan inactif, quand Franck Guillou le réactive, alors le plan redevient actif et, si son échéance est dans les 7 jours, une intervention préventive est créée à la génération suivante.

Scénario 3 — droit insuffisant (RG8) Étant donné un utilisateur connecté avec le profil Technicien, quand il ouvre le plan, alors la commande « Suspendre » n’est pas proposée, et une tentative directe (adresse de la page saisie à la main) est refusée et tracée.

3. Scénario pour RG7 : Étant donné le plan « Ascenseur A – contrôle mensuel » de la Corderie, d’échéance le 31/10/2026, dont l’intervention préventive est encore « ouverte », quand un utilisateur affiche la liste des échéances de la Corderie le 02/11/2026, alors cette échéance apparaît en orange avec la mention « en retard de 2 jours ». Un second scénario vérifie la limite : le 31/10/2026, la même échéance n’est pas en retard (la date du jour ne la dépasse pas).

1. Classes d’analyse (une par table métier, sans clés étrangères) :

Les identifiants techniques (id_client…) ne sont pas des attributs métier en analyse ; fidelite, codé 0 ou 1, est un Booléen ; telephone peut être vide, d’où [0..1].

2. Associations :

ON DELETE SET NULL traduit une règle : si un client est supprimé (par exemple à l’expiration de sa durée de conservation), ses réservations sont conservées sans lui (pour les statistiques et la comptabilité). C’est ce qui justifie la multiplicité 0..1 côté Client.

3. Deux règles de gestion écrites en contraintes : canal IN ('site','app','plateforme','reception') (RG : une réservation provient d’un de ces quatre canaux) et fidelite IN (0,1) (adhésion au programme : oui ou non). On peut aussi citer les NOT NULL (une réservation a toujours des dates d’arrivée et de départ).

Lien caché : code_site CHAR(3) désigne un établissement (PNF, COR, ROY…), mais aucune clé étrangère ne le protège : rien n’empêche d’enregistrer « XYZ ». Dans le modèle, on fait apparaître une classe Etablissement et une association Reservation 0..* — 1 Etablissement ; dans la base, on propose une table de référence et une clé étrangère (SLAM-03). Une autre règle manque : rien n’impose date_depart > date_arrivee.

4. Un attribut qui se calcule à partir d’autres informations est dérivé : on le note avec une barre oblique, /dernierSejour. Le risque d’une colonne recopiée est l’incohérence : si une réservation est modifiée ou annulée sans mettre à jour dernier_sejour, les deux informations divergent. Il faut soit la calculer à la demande, soit la maintenir par un traitement fiable (déclencheur, SLAM-05).

1. Acteurs et cas :

Sabrina Morel est une personne : l’acteur est le rôle Comptable. Le fournisseur n’est pas un acteur : les commandes restent hors de l’application.

2. «include» : « Déclarer les pièces utilisées » et « Faire l’inventaire d’une réserve » incluent « Rechercher une pièce » (toujours nécessaire, mis en commun). «extend» : « Alerter le responsable » étend « Déclarer les pièces utilisées », au point d’extension « après la sortie », avec la condition {stock de la pièce inférieur au seuil de l’établissement}. La Messagerie est associée à ce cas d’extension.

3. Diagramme attendu :

• sujet : rectangle « KerMaint – pièces détachées » contenant tous les cas ;
• acteurs à gauche : Technicien et Responsable technique (si on reprend la généralisation du cours, triangle creux sur Technicien) ; Comptable ;
• acteur à droite : rectangle «actor» Messagerie ;
• associations (traits pleins) : Technicien — Déclarer les pièces utilisées ; Responsable technique — Gérer le catalogue des pièces, Fixer les seuils d’alerte, Faire l’inventaire d’une réserve ; Comptable — Consulter la valeur du stock ; Messagerie — Alerter le responsable ;
• «include» (pointillés, pointe ouverte) : de « Déclarer les pièces utilisées » vers « Rechercher une pièce » ; de « Faire l’inventaire d’une réserve » vers « Rechercher une pièce » ;
• «extend» (pointillés, pointe ouverte) : de « Alerter le responsable » vers « Déclarer les pièces utilisées », dont l’ellipse porte le compartiment « extension points : après la sortie » ; une note reliée à la flèche indique la condition.

On peut aussi rattacher « Gérer le catalogue des pièces » à « Rechercher une pièce » par «include» si la modification d’une pièce commence par la retrouver.

4. Hors périmètre : les commandes aux fournisseurs (« par téléphone »). On l’écrit explicitement dans les spécifications, dans une rubrique « Exclusions » ou en Won’t have this time dans la priorisation MoSCoW : ce qui n’est pas écrit risque d’être réclamé à la recette (CEJMA-03).

5. Description textuelle de « Déclarer les pièces utilisées » :

2. Taux de réussite : T1 = 5 ÷ 5 = 100 % ; T2 = 2 ÷ 5 = 40 % ; T3 = 3 ÷ 5 = 60 % ; global = (5 + 2 + 3) ÷ 15 = 10 ÷ 15 ≈ 66,67 %. Temps moyen de T1 = (40 + 55 + 38 + 62 + 45) ÷ 5 = 240 ÷ 5 = 48 secondes. Un utilisateur (62 s) dépasse 60 secondes.

La moyenne ne suffit pas : l’exigence « en moins de 60 secondes » vise chaque utilisateur, et un sur cinq ne la respecte pas. Il faut préciser l’exigence avec le client (par exemple « 4 utilisateurs sur 5 en moins de 60 secondes ») et regarder pourquoi cet utilisateur a été plus lent.

3. T2 est prioritaire : seulement 40 % de réussite, et les deux réussites ont pris 150 et 170 secondes. Hypothèse : le filtre des contrôles en retard n’est pas visible (ou l’état « en retard » ne se distingue pas assez). Vérification : observer les utilisateurs refaire la tâche en pensant à voix haute, puis tester une version avec un bouton « En retard » en tête de liste sur 3 à 5 nouveaux utilisateurs. T3 (60 %) vient ensuite : le cas « contrôle fait par un prestataire » n’est peut-être pas prévu dans le modèle, question à poser au client.

2. Données et calculs :

• Option A : 1re année = 13 640 + 1 120 = 14 760 € ; puis + 1 000 € par an.
• Option B : abonnement annuel = 25 × 13 × 12 = 3 900 € ; coûts de départ = 2 400 + 2 240 + formation (12 × 3 × 30 + 6 × 40 = 1 080 + 240 = 1 320) + choix (10 × 40 = 400) = 6 360 € ; 1re année = 3 900 + 6 360 = 10 260 € ; puis + 3 900 + 500 = 4 400 € par an.

Sur 3 ans, A coûte 16 760 € et B 19 060 € (écart de 2 300 € en faveur de A) ; sur 5 ans, A coûte 18 760 € et B 27 860 € (écart de 9 100 €). B est moins cher les deux premières années, mais devient plus cher à partir de la 3e année.

Chapitres à mobiliser pour B : CEJMA-01 (modèle SaaS, dépendance), CEJMA-03 et CEJMA-04 (contrat, niveaux de service, réversibilité), CEJMA-08 (sous-traitance des données personnelles).

4. Exemple de recommandation : « Nous recommandons l’option A, intégrée à KerMaint : sur 3 ans, son coût total est inférieur de 2 300 € (9 100 € sur 5 ans), elle évite la double saisie et garde les données chez Kervanet. L’option B ne coûte moins que les deux premières années. Limites : les chiffres de B reposent sur une offre type et la provision d’évolutions de A est une estimation ; une fonction riche du logiciel du marché (planning des prestataires) n’a pas été valorisée. »

2. Modèle complété :

• Piece : reference : Texte ; libelle : Texte ; prixUnitaireHT : Décimal.
• Association Etablissement — Piece « stocke », multiplicités 0..* côté Piece et 0..* côté Etablissement, avec la classe d’association StockPiece : quantite : Entier ; seuilAlerte : Entier.
• Association Intervention — Piece « consomme », 0..* côté Piece et 0..* côté Intervention, avec la classe d’association Consommation : quantite : Entier.

La quantité en stock n’est ni une caractéristique de la pièce (elle varie selon l’établissement) ni de l’établissement (elle varie selon la pièce) : elle appartient au couple (établissement, pièce), donc à l’association. De même, la quantité consommée appartient au couple (intervention, pièce). La classe d’association se dessine comme une classe reliée au trait de l’association par des pointillés.

3. Objets et liens créés le 12/11/2026 : une intervention (ordinaire, corrective) sur l’équipement « Ascenseur A » (Corderie), réalisée par Nadia Poitevin ; deux liens « consomme » de cette intervention, chacun avec un objet Consommation : courroie (quantite = 1) et joint (quantite = 2). Les objets StockPiece (Corderie, courroie) et (Corderie, joint) existent déjà ; leurs quantités diminuent de 1 et de 2. Aucun nouvel objet Piece ni Etablissement n’est créé.

1. Diagramme de séquence attendu, dans l’ordre de haut en bas :

• cadre sd Générer les interventions préventives ;
• lignes de vie : Planificateur (acteur), : CtrlGeneration, : PlanPreventif (les plans), Messagerie (acteur secondaire, ou : Messagerie) ; la ligne de vie : InterventionPreventive n’apparaît qu’à sa création ;
• message synchrone (pointe pleine) Planificateur → CtrlGeneration : generer(dateDuJour) ;
• message synchrone CtrlGeneration → PlanPreventif : plansActifs(), puis réponse en pointillés : plans = plansActifs() ;
• fragment loop [pour chaque plan actif] contenant :
  • message synchrone CtrlGeneration → plan : aGenerer(dateDuJour) et sa réponse a = aGenerer ;
  • fragment opt [a = vrai] (échéance ≤ date du jour + 7 et aucune intervention non clôturée) contenant : message de création (pointillés, pointe ouverte) CtrlGeneration → : InterventionPreventive, qui arrive sur la tête de la nouvelle ligne de vie : créer(plan, 3) ; puis message asynchrone (trait plein, pointe ouverte) CtrlGeneration → Messagerie : notifier(technicien, intervention) ;
• réponse finale CtrlGeneration → Planificateur : generer : nombre d'interventions créées.

2. Corrections :

• noms des lignes de vie non soulignés : le soulignement des objets appartient à UML 1 ; en UML 2, la tête contient nom : Type sans soulignement ;
• une réponse se dessine en pointillés ;
• l’envoi à la Messagerie n’attend pas de résultat : message asynchrone, pointe ouverte ;
• le participant créé n’existe pas avant sa création : sa tête est placée à la hauteur du message de création, qui arrive dessus.

3. Diagramme d’activité attendu : nœud initial → « Lire les plans actifs » → fusion (losange) → décision [reste un plan] / [plus de plan] ; sur [reste un plan] : « Prendre le plan suivant » → décision [échéance ≤ jour + 7 et aucune intervention ouverte] → « Créer l’intervention préventive » → « Envoyer la notification » → retour à la fusion ; [sinon] → retour direct à la fusion ; sur [plus de plan] : « Journaliser le nombre d’interventions créées » → fin d’activité. Les gardes de chaque décision sont exclusives et couvrent tous les cas.

4. Date limite = 9/11/2026 + 7 jours = 16/11/2026.

Trois interventions sont créées (P1, P4, P6), donc trois notifications.

5. La formulation « dont l’échéance tombe dans les 7 jours » laisse croire qu’une échéance passée n’est pas concernée : P4 ne serait jamais générée et le contrôle serait oublié, précisément ce que le module doit empêcher. Formulation proposée : « chaque nuit à 5 h, une intervention préventive est créée pour chaque plan actif dont l’échéance est antérieure ou égale à la date du jour + 7 jours, sauf s’il existe déjà une intervention non clôturée pour ce plan ». Test de recette : « Étant donné un plan actif d’échéance le 05/11/2026 sans intervention, quand la génération s’exécute le 09/11/2026, alors une intervention préventive est créée et l’échéance apparaît en retard. »

Phase 1

1. Récits et classement :

• Demande 1 (règle de gestion, qui modifie RG3) : « En tant que responsable technique, je veux qu’un plan mensuel prévu le dernier jour du mois garde une échéance au dernier jour de chaque mois afin que le calendrier des contrôles ne glisse pas. » Critère : « Étant donné un plan mensuel de départ le 31/10/2026, quand on calcule ses cinq échéances suivantes, alors on obtient 30/11/2026, 31/12/2026, 31/01/2027, 28/02/2027 et 31/03/2027. »
• Demande 2 (besoin fonctionnel, avec une règle de calcul) : « En tant que responsable technique, je veux voir par établissement le taux de contrôles faits à l’heure sur une période afin de repérer les sites qui décrochent. » Critère : « Étant donné les 12 contrôles de l’annexe 3, quand j’affiche septembre-octobre 2026, alors Port-Neuf affiche 75 %, la Corderie 33,33 %, Royan 100 %, Remblai 50 %, l’ensemble 66,67 %. » Exigence non fonctionnelle associée : affichage en moins de 2 secondes.

2. Avec RG3, chaque échéance est calculée à partir de la précédente. Quand on passe par un mois de 30 jours, le 31 devient 30, et le jour 30 est ensuite conservé pour tous les mois suivants : l’information « dernier jour du mois » est perdue. RG3 bis : la k-ième échéance d’un plan = date de départ + k × périodicité ; si le jour de départ n’existe pas dans le mois obtenu, on prend le dernier jour de ce mois. Le jour de référence reste celui de la date de départ.

3. Modifications du modèle :

• PlanPreventif : ajouter dateDepart : Date et rangEcheance : Entier (k de la prochaine échéance) ; prochaineEcheance devient un attribut dérivé (/prochaineEcheance), calculé par echeance(k) ; l’opération avancerEcheance() incrémente le rang.
• Indicateur : opération de calcul sur Etablissement, ou requête de consultation ; il exige que l’intervention préventive garde son échéance prévue et sa date de réalisation (ajouter dateRealisation : Date [0..1] à InterventionPreventive si elle n’existe pas).
• Plans existants : il faut leur donner une date de départ et un rang. Pour ne pas les décaler, on prend comme départ leur prochaine échéance actuelle et un rang 0 : aucun contrôle déjà planifié ne change de date.

4. Démarche et outils : mettre à jour les règles et le diagramme de classes (outil de modélisation) ; écrire la fonction en PHP 8.3 dans l’environnement du centre ; écrire d’abord le cahier de recette (cas de fin de mois, année bissextile) puis le code ; exécuter les tests ; calculer l’indicateur sur l’annexe 3 et comparer. Questions à poser à la commission (le client) : un plan qui démarre un 30 doit-il rester au 30, ou passer au dernier jour du mois (il faudrait alors une option « fin de mois ») ? Pour l’indicateur, un contrôle non encore réalisé dont l’échéance est passée compte-t-il comme « pas à l’heure » ? La période se choisit-elle sur l’échéance ou sur la date de réalisation ?

Phase 2

5. Fonction (PHP 8.3) :

function echeance(DateTimeImmutable $depart, int $mois, int $k): DateTimeImmutable
{
    if (!in_array($mois, [1, 3, 6, 12], true) || $k < 0) {
        throw new InvalidArgumentException("Paramètres refusés : $mois mois, rang $k");
    }
    $debutMois = $depart->modify('first day of this month')->modify('+' . ($mois * $k) . ' months');
    $jour = min((int) $depart->format('j'), (int) $debutMois->format('t'));
    return $debutMois->setDate((int) $debutMois->format('Y'), (int) $debutMois->format('n'), $jour);
}

On se place au premier jour du mois de départ (qui existe toujours), on ajoute k × périodicité mois, puis on choisit le plus petit entre le jour de départ et le nombre de jours du mois obtenu (t).

6. Cahier de recette et résultat de l’exécution :

MP-15 : 2026-10-31, 1 mois, k = 2 -> 2026-12-31 conforme
MP-16 : 2026-10-31, 1 mois, k = 4 -> 2027-02-28 conforme
MP-17 : 2027-11-30, 3 mois, k = 1 -> 2028-02-29 conforme
MP-18 : 2026-11-16, 12 mois, k = 1 -> 2027-11-16 conforme
MP-19 : 2026-08-31, 6 mois, k = 3 -> 2028-02-29 conforme
MP-20 : 2026-10-31, 1 mois, k = 0 -> 2026-10-31 conforme
MP-21 : Paramètres refusés : 2 mois, rang 1 -> conforme
7 tests conformes sur 7

7. Indicateur (contrôle à l’heure si réalisé le jour de l’échéance ou avant) :

Contrôles en retard : Port-Neuf, échéance 15/09, 3 jours ; Corderie, 30/09, 6 jours ; Corderie, 10/10, 2 jours ; Remblai, 25/09, 19 jours. Les cas « réalisé le jour même » (Port-Neuf 15/10, Royan 05/10) comptent à l’heure : c’est un cas limite à faire figurer dans les critères d’acceptation.

8. Réponses à la commission :

1. modify('+1 month') déborde sur le mois suivant quand le jour n’existe pas : en PHP 8.3, le 31/10/2026 + 1 mois donne le 01/12/2026, et le 31/01/2027 + 1 mois le 03/03/2027. Le calcul doit partir du premier jour du mois, puis ramener le jour au dernier jour possible.

2. Par des tests de non-régression : les cas MP-01 à MP-14 de la recette initiale sont rejoués, et une vérification compare, pour chaque plan existant, la prochaine échéance avant et après la migration (elle doit être identique, puisque le rang 0 part de l’échéance actuelle). Ces tests sont automatisés et intégrés au dépôt (SLAM-10, SLAM-11).

3. Non, pas dans le calcul présenté : il ne porte que sur les contrôles réalisés. Un contrôle en retard non encore fait est pourtant le pire cas. Je propose de le compter comme « pas à l’heure » dès que son échéance est dépassée, et de l’afficher à part ; c’est une règle à faire valider par Franck Guillou avant le développement.