Analyser le besoin et le modéliser

1. Du besoin à l’application

AUne demande de Kervanet

Le lundi 28 septembre 2026, Franck Guillou, responsable technique des bâtiments de Kervanet Hôtels & Résidences, écrit au centre de services de Vellacor (ticket VEL-2026-4203). Aujourd’hui, l’entretien périodique des équipements des sept établissements (chaudières, climatisations, ascenseurs, organes de sécurité) est suivi dans un classeur de tableur du partage Qualite : 58 lignes, une par contrôle à faire, avec la date du dernier passage. Sur les douze derniers mois, 9 contrôles ont été faits avec plus de 30 jours de retard et 2 ont été oubliés. Il demande « un module de maintenance préventive dans KerMaint », l’application de gestion des interventions que Vellacor développe et maintient pour Kervanet.

C’est un développement nouveau : il n’entre pas dans le forfait de maintenance et fera l’objet d’un devis (contrat : CEJMA-03). Anaïs Lecoq, responsable du pôle développement, confie l’analyse à Sarah Cherif, alternante en BTS SIO option SLAM, sous sa supervision. Tout le chapitre suit ce travail, du premier entretien à la validation du modèle.

BCe que fait l’analyste

Le client exprime un besoin avec ses mots (« ne plus oublier de contrôles »). L’analyste le transforme en spécifications précises, puis en modèle : un ensemble de textes et de diagrammes qui décrivent ce que fera l’application, sans encore dire comment elle sera programmée.

CTon rôle de développeur SLAM

Le référentiel attend que tu participes aux spécifications et à l’architecture, en équipe. À l’épreuve E6, la commission te remet une expression de besoins : tu l’analyses, proposes des spécifications et une démarche, puis réalises et fais la recette (exercice 10).

2. Les cycles de production

ALes activités du développement

Quel que soit le cycle, on retrouve les mêmes activités :

BTrois grandes familles de cycles

Tu as vu en B1-10 l’approche prédictive (cascade, cycle en V) et l’approche agile (Scrum, Kanban). Pour une application, on les retrouve sous trois formes :

Elles se combinent : KerMaint évolue en Scrum (B1-10), et Sarah prototype les écrans avant un sprint.

Une approche plus récente, DevOps, rapproche le développement (development) et l’exploitation (operations) : tests, intégration et déploiement automatisés pour livrer souvent et sans risque. Ses outils (intégration continue) sont étudiés en SLAM-10.

CLes acteurs de la production

DLes références communes

Pour que tout le monde se comprenne, l’analyse s’appuie sur des références partagées :

3. Recueillir le besoin

AIdentifier les parties prenantes

La première question est : qui est concerné ? Ceux qui paient, ceux qui décident, ceux qui utiliseront l’application, ceux qui subiront ses effets. Sarah dresse la liste avec Anaïs : Franck Guillou (demandeur), les 12 utilisateurs réguliers de KerMaint sur tablette (techniciens de maintenance), les directeurs d’établissement (qui reçoivent les prestataires), Gwenaëlle Le Bihan (budget), Mélodie Rochereau (backlog), Thomas Guéguen (serveur). Oublier un groupe, c’est découvrir son besoin à la recette.

BLes techniques de recueil

Sarah combine quatre techniques : un entretien avec Franck Guillou le mercredi 30 septembre, une demi-journée d’observation avec Mathis Le Goff à Port-Neuf le jeudi 1er octobre, l’analyse du classeur des contrôles et un atelier de récits utilisateur le mercredi 7 octobre.

CLe cadre juridique du besoin

Un besoin s’inscrit dans des règles de droit. L’analyste ne les tranche pas, mais il doit les repérer pour qu’elles deviennent des exigences, et alerter le client : c’est une part du devoir de conseil du prestataire (CEJMA-03).

4. Formaliser le besoin

ALes acteurs

On distingue l’acteur principal, qui déclenche une utilisation pour en tirer un résultat, et l’acteur secondaire, qui est sollicité par l’application (la messagerie qui envoie les notifications). Un acteur peut être un système : la tâche planifiée qui lance chaque nuit la génération des interventions est représentée par un acteur Planificateur.

BBesoins fonctionnels et non fonctionnels

La distinction a été vue en B1-10 : un besoin fonctionnel dit ce que l’application permet de faire, une exigence non fonctionnelle dit avec quelle qualité ou dans quelles limites. Pour ne pas oublier d’exigences non fonctionnelles, on parcourt une grille : celle de la norme ISO/IEC 25010:2023, qui décrit la qualité d’un produit logiciel en neuf caractéristiques.

CLes règles de gestion

RG3 a été précisée pendant l’atelier : Franck voulait d’abord « un an après le dernier contrôle », mais un contrôle fait avec 10 jours de retard aurait décalé toutes les échéances suivantes. Calculer à partir de l’échéance précédente garde un calendrier stable.

DLe glossaire

Franck dit « visite », Mathis « contrôle », le classeur « entretien ». Un glossaire fixe un seul mot par notion, avec sa définition : plan préventif, point de contrôle, échéance, intervention préventive, intervention corrective. Ces mots deviendront les noms des classes (l’intervention corrective, ordinaire, sera simplement la classe Intervention) : le glossaire évite que le modèle et l’interface parlent deux langues différentes.

5. Écrire des récits utilisateur

ALa forme d’un récit

Tu as rencontré le récit utilisateur (user story) en B1-10 : « En tant que rôle, je veux action afin de bénéfice ». La troisième partie est la plus importante : elle donne la raison du besoin, qui permet de proposer une meilleure solution ou de prioriser.

BLa grille INVEST d’un bon récit

Les praticiens agiles vérifient chaque récit avec la grille INVEST :

• Indépendant : il peut être réalisé sans attendre un autre récit ;
• Négociable : c’est une base de discussion, pas un contrat figé ;
• de Valeur : il apporte quelque chose à un utilisateur ou au client ;
• Estimable : l’équipe comprend assez bien pour l’estimer en points ;
• Small (petit) : il tient dans un sprint ;
• Testable : on sait dire s’il est terminé.

CLes critères d’acceptation

Une écriture très répandue, issue du développement piloté par le comportement, est le format Étant donné / Quand / Alors : le contexte de départ, l’action, le résultat attendu.

6. Représenter les cas d’utilisation

AUML en bref

UML n’est pas une méthode : il dit comment dessiner, pas dans quel ordre travailler. En BTS SIO, on attend surtout les diagrammes de cas d’utilisation (avec leurs descriptions), de classes et de séquence, et la lecture d’un diagramme d’activité, dessinés avec un outil de modélisation (Modelio, PlantUML…).

BLes éléments du diagramme

CLes relations entre cas

Ces trois relations sont les plus mal utilisées : retiens leur sens.

• «include» : le cas de base contient toujours le cas inclus. On ne peut pas gérer un plan ni enregistrer un contrôle sans rechercher un équipement : la recherche est mise en commun dans un cas inclus. La flèche part du cas qui inclut.
• «extend» : le cas qui étend ajoute parfois un comportement au cas de base, à un endroit précis (le point d’extension, listé dans un compartiment du cas étendu) et sous une condition. Le cas de base est complet sans lui : un contrôle conforme ne crée rien. La flèche part du cas qui étend, vers le cas étendu.
• Généralisation entre acteurs : l’acteur spécialisé peut faire tout ce que fait l’acteur général, et plus. Le responsable technique hérite des cas du technicien.

DLa description textuelle d’un cas

Le diagramme ne montre que les noms. Le contenu de chaque cas important se décrit dans une fiche textuelle, qui sert de référence aux développeurs et aux testeurs.

7. Modéliser les classes

ADécrire une classe

Une classe se dessine comme un rectangle à trois compartiments : le nom (au singulier, avec une majuscule), les attributs, les opérations. La syntaxe d’un attribut est nom : Type [multiplicité] : dateMes : Date [0..1] veut dire que la date de mise en service d’un équipement peut être absente ; sans crochets, l’attribut a exactement une valeur. En analyse, on se limite à quelques opérations significatives (echeanceSuivante() : Date) ; la visibilité (+, −, #) et le détail des méthodes relèvent de la programmation objet (SLAM-02).

BAssociations et multiplicités

CLes liens particuliers

• La composition (losange plein, côté du tout) indique qu’une partie n’existe pas sans son tout et n’appartient qu’à lui : un point de contrôle n’a pas de sens hors de son plan ; supprimer le plan supprime ses points.
• L’agrégation (losange creux, côté du tout) indique un simple regroupement, sans dépendance de vie : une équipe et ses techniciens. Elle est peu utilisée ; dans le doute, une association simple suffit.
• La généralisation (triangle creux côté classe générale) indique qu’une classe spécialisée est une sorte de classe générale : elle hérite de ses attributs, de ses opérations et de ses associations. Une intervention préventive est une intervention, avec en plus une échéance prévue et un résultat.

Dans le module, la classe Intervention n’est pas abstraite : une intervention signalée par la réception ou créée par RG6 est une intervention ordinaire, dite corrective, qui n’a rien de plus que ce que décrit la classe Intervention. Seule l’intervention préventive ajoute des informations (échéance prévue, résultat) : elle seule mérite une sous-classe. Ce choix est repris tel quel dans le code de SLAM-02, où Intervention est une classe concrète et InterventionPreventive sa fille. À l’inverse, en SLAM-02, la classe Equipement est abstraite : un équipement est toujours une climatisation, une chaudière, un ascenseur…

Quand une association porte elle-même des informations, on la représente par une classe d’association, reliée au trait de l’association par des pointillés. Le résultat de chaque point lors d’une intervention préventive (conforme ou non, commentaire) pourrait se modéliser ainsi entre InterventionPreventive et PointControle ; tu le pratiqueras en exercice 8.

DLes frontières avec les autres chapitres

Le même métier se modélise trois fois, à trois niveaux : ne les confonds pas.

ERetrouver le modèle d’une application existante

Le module s’ajoute à KerMaint, qui existe depuis 2022. Avant de modéliser le neuf, Sarah reconstitue le modèle de l’existant : c’est la rétro-conception (reverse engineering), qui part de ce qui fonctionne (base de données, écrans, code) pour retrouver le modèle.

Le schéma de la base de KerMaint (voir le fil rouge) se lit ainsi : chaque table métier donne une classe ; chaque clé étrangère donne une association ; une clé étrangère obligatoire (NOT NULL) donne la multiplicité 1, une clé facultative donne 0..1 ; une contrainte CHECK donne une règle de gestion. Les outils de modélisation savent dessiner le diagramme à partir de la base ; on peut aussi interroger le catalogue du SGBD.

SELECT TABLE_NAME AS table_source, COLUMN_NAME AS colonne,
       REFERENCED_TABLE_NAME AS table_cible
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = 'kermaint' AND REFERENCED_TABLE_NAME IS NOT NULL
ORDER BY TABLE_NAME, COLUMN_NAME;

+--------------+----------+---------------+
| table_source | colonne  | table_cible   |
+--------------+----------+---------------+
| equipement   | id_etab  | etablissement |
| intervention | id_equip | equipement    |
| intervention | id_tech  | technicien    |
| technicien   | id_etab  | etablissement |
+--------------+----------+---------------+

Elle révèle aussi des manques : aucune colonne ne relie une intervention à un plan préventif ; la spécialisation InterventionPreventive du modèle cible demandera une évolution du schéma (SLAM-03, migration en SLAM-08).

8. Décrire les échanges et les traitements

ALe diagramme de séquence

Ce diagramme détaille les étapes 4 à 7 du scénario nominal et l’alternative A1 de la fiche « Enregistrer un contrôle ». Les messages correspondent à des opérations des classes : enregistrerResultat() doit figurer dans InterventionPreventive, avancerEcheance() dans PlanPreventif. C’est ainsi qu’on vérifie la cohérence des diagrammes : tout message reçu par un objet doit être une opération de sa classe. Ici, avancerEcheance() manque encore au diagramme de classes : il faudra l’ajouter (Sarah l’a noté pour la version suivante).

BLe diagramme d’activité

Les gardes d’une même décision doivent être exclusives et couvrir tous les cas : [conforme] et [non conforme]. Le diagramme d’activité convient pour montrer un processus métier à un client, qui le lit plus facilement qu’un diagramme de séquence.

9. Choisir une architecture

ALes grandes typologies

L’hébergement fait aussi partie des choix : serveur du client (KV-KERMAINT), prestataire, ou logiciel à la demande (SaaS), comme le logiciel de gestion hôtelière de Kervanet (CEJMA-01).

BL’architecture retenue pour le module

Anaïs et Sarah comparent deux options : intégrer le module dans KerMaint ou acheter un logiciel de maintenance du marché en SaaS (comparaison chiffrée en exercice 7). Elles proposent l’intégration :

• les écrans du module sont de nouvelles vues de KerMaint, utilisées dans le navigateur des tablettes ;
• la logique métier (RG1 à RG9) est programmée dans le framework de KerMaint ;
• les données sont dans la base MariaDB existante : équipements et techniciens sont partagés, sans double saisie ;
• la génération nocturne (RG4) est une tâche planifiée sur KV-KERMAINT à 5 h, qui joue le rôle de l’acteur Planificateur ;
• les notifications passent par l’envoi de courriels que KerMaint utilise déjà ;
• l’export PDF du registre utilise la bibliothèque déjà présente dans KerMaint, sous licence LGPL, autorisée par la politique de Vellacor (CEJMA-02).

10. Chiffrer une solution

ALa composition du coût

BLe devis du module

La charge s’estime par activité et par personne, en jours-homme (j-h), puis se valorise aux prix de journée de Vellacor (B1-10) : cheffe de projet ou responsable technique 680 € HT, technicien ou développeur 560 € HT, alternant 400 € HT.

11. Maquetter une interface

AMaquettes et prototypes

On maquette sur papier, avec un outil de conception d’interfaces (Penpot, outil libre, ou des outils en ligne du marché) ou directement en HTML et CSS. La maquette respecte la charte graphique du client quand elle existe (couleurs de Kervanet, B1-08), mais pour un outil interne sur tablette, la lisibilité prime.

BLes principes d’ergonomie

L’ergonomie d’une interface, c’est sa capacité à être utilisée efficacement, sans erreur et avec satisfaction par ses utilisateurs, dans leur situation réelle. La norme ISO 9241-110:2020 énonce des principes d’interaction ; en France, on utilise aussi beaucoup les critères ergonomiques de Christian Bastien et Dominique Scapin (INRIA, 1993), conçus pour évaluer une interface.

CConcevoir pour la tablette et pour tous

L’accessibilité, étudiée en B1-09 avec le RGAA pour les sites publics, s’applique aussi à une application interne comme bonne pratique : elle profite à tous les utilisateurs (gants, lumière forte, fatigue) et à ceux qui ont un handicap.

DÉvaluer et valider une interface

On évalue une maquette ou un prototype de deux façons :

• l’inspection : un spécialiste examine l’interface critère par critère et liste les défauts ;
• le test utilisateur : de vrais utilisateurs réalisent des tâches précises sur le prototype, sans aide ; on observe et on mesure le taux de réussite, le temps et les erreurs, puis on recueille leur avis.

12. Valider le modèle avec le client

AFaire comprendre le modèle

Franck Guillou ne lit pas l’UML. Sarah prépare donc une revue de validation avec des supports adaptés :

• les récits et leurs critères d’acceptation, en français courant ;
• les règles de gestion, chacune illustrée d’un exemple chiffré (les trois plans de RG3) ;
• le diagramme d’activité, qui ressemble à un logigramme ;
• la maquette et le prototype, sur une vraie tablette ;
• des scénarios déroulés de bout en bout (« le 9 novembre à 5 h, KerMaint crée l’intervention… »).

Les diagrammes de classes et de séquence sont validés en interne par Anaïs (cohérence avec les récits et les règles).

BLa revue du 16 octobre 2026

La revue réunit Franck Guillou, Mélodie Rochereau, Anaïs Lecoq, Sarah et Mathis Le Goff. Six scénarios sont déroulés. Trois remarques sont retenues : un plan doit pouvoir être suspendu pendant la fermeture d’un établissement (d’où l’attribut actif de PlanPreventif) ; un organe de sécurité non conforme doit prévenir immédiatement le responsable (exigence de sûreté) ; l’export PDF n’est pas indispensable pour la première version (US5 reste Should). Le compte rendu, avec la version 1.0 des spécifications, est validé par Franck Guillou et Mélodie Rochereau.

CEt après ?

Le devis est envoyé le 19 octobre 2026 à Gwenaëlle Le Bihan. S’il est accepté, US1 à US4 entreront dans le backlog produit après l’objectif en cours (fin prévue le 11 décembre, B1-10).

Erreurs fréquentes et points de vigilance

• Écrire la solution au lieu du besoin (« ajouter une table ») : le besoin vient du client, la solution du prestataire.
• Laisser des exigences non fonctionnelles non mesurables (« rapide », « simple »).
• Confondre acteur et personne, ou nommer un cas d’utilisation par un nom ou par un clic.
• Inverser le sens des flèches «include» (de la base vers l’inclus) et «extend» (de l’extension vers la base).
• Placer la multiplicité du mauvais côté de l’association, ou mettre des clés étrangères dans les attributs d’une classe d’analyse.
• Mettre le losange de composition du côté de la partie au lieu du tout.
• Souligner les noms des lignes de vie (notation d’UML 1) ou dessiner une réponse en trait plein.
• Des diagrammes incohérents entre eux : un message de séquence qui ne correspond à aucune opération.
• Faire valider des diagrammes par un client qui ne les lit pas, au lieu de scénarios et de maquettes.

L’essentiel du chapitre

• Analyser, c’est passer du besoin du client à des spécifications vérifiables, puis à un modèle validé, avant de développer.
• Cycles séquentiels, itératifs (dont agiles) ou avec prototypage : en agile, l’analyse est découpée et affinée avant chaque sprint.
• Le besoin se recueille par entretien, observation, atelier, questionnaire et analyse de l’existant ; ses contraintes juridiques deviennent des exigences.
• On formalise : acteurs, besoins fonctionnels, exigences non fonctionnelles mesurables (grille ISO/IEC 25010:2023), règles de gestion numérotées, glossaire.
• Un récit utilisateur (« En tant que…, je veux… afin de… ») respecte la grille INVEST et porte des critères d’acceptation (Étant donné / Quand / Alors).
• UML 2.5.1 : cas d’utilisation (acteurs, sujet, «include», «extend», fiche textuelle), classes (attributs, opérations, associations, multiplicités, composition, généralisation), séquence (lignes de vie, messages synchrones, réponses, fragments), activité (actions, décisions, fourches, couloirs).
• La rétro-conception reconstruit le modèle d’un existant à partir de sa base, de son code et de ses écrans.
• L’architecture (client-serveur, couches, monolithe, services, mobile, hébergement) se choisit selon l’intégration, le coût et les compétences.
• Le coût d’une solution inclut réalisation, acquisition, exploitation, maintenance, coûts internes et sortie : on compare des coûts totaux de possession.
• Une interface se maquette, se prototype et s’évalue (critères ergonomiques, test utilisateur), en appliquant l’accessibilité dès le départ.
• Le modèle se valide avec le client par des scénarios et des maquettes, avec une traçabilité des besoins jusqu’aux tests.

Sources et références

• Arrêté du 29 avril 2019 portant définition et fixant les conditions de délivrance du BTS « Services informatiques aux organisations », modifié par les arrêtés du 8 juillet 2024 et du 22 novembre 2024 : annexe I.B, bloc 2 option B, compétence « Concevoir et développer une solution applicative » et savoirs associés ; définition de l’épreuve E6.
• OMG, Unified Modeling Language, version 2.5.1, document formal/17-12-05, décembre 2017 (omg.org/spec/UML/2.5.1) : notation des cas d’utilisation (§ 18.1.4), des associations (§ 11.5.4), de la généralisation (§ 9.2.4), des attributs (§ 9.5.4), des interactions (§ 17.2.4 à 17.6.4) et des activités (§ 15.2.4, 15.3.4, 15.6.4) ; consulté le 20/10/2026.
• ISO/IEC 25010:2023, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model, 2e édition, novembre 2023 (fiche iso.org : neuf caractéristiques, norme publiée en anglais seulement) ; noms anglais des caractéristiques relevés sur quality.arc42.org ; traduction française libre ; consultés le 20/10/2026.
• ISO 9241-110:2020, Ergonomics of human-system interaction — Part 110: Interaction principles (fiche iso.org : 2e édition, mai 2020, confirmée en 2025) ; consultée le 20/10/2026.
• C. Bastien, D. Scapin, Ergonomic criteria for the evaluation of human-computer interfaces, rapport technique INRIA RT-0156, 1993, critères présentés en anglais et en français (inria.hal.science/inria-00070012, notice consultée le 20/10/2026).
• W3C, WCAG 2.2, critères 2.5.8 « Target Size (Minimum) » (24 × 24 px, niveau AA) et 2.5.5 « Target Size (Enhanced) » (44 × 44 px, niveau AAA), pages « Understanding » de w3.org, consultées le 20/10/2026.
• Scrum Guide (novembre 2020), récits utilisateur et MoSCoW : voir B1-10. RGAA 4.1.2 et obligations d’accessibilité : voir B1-09.
• Requête de rétro-conception exécutée le 20/10/2026 sur la machine de laboratoire LAB-UBU01 (MariaDB 10.11 ; le catalogue information_schema utilisé est le même en MariaDB 11.8), sur une copie du schéma de KerMaint.