Maj du git depuis la derniere fois

TP_BD/fichiereponsetp1.sql

@@ -36,3 +36,12 @@ SELECT id, nom_produit, prix_unitaire INTO v_produit FROM Produit WHERE id=1;
 DBMS_OUTPUT.PUT_LINE(v_produit.id || ' ' || v_produit.nom || ' ' || v_produit.prix_unitaire);
 END;
 /
+
+--4 
+
+DECLARE 
+CURSOR c.client_commande is SELECT c.id,c.prenom,c.nom,c.email,c.ville,co.date_achat,co.id_produit,lc.quantite FROM Client c JOIN Commande co ON c.id=co.client_id JOIN ligne_commande WHERE co.date_achat=;
+
+
+
+

TP_BD/fichiereponsetp2.sql

@@ -0,0 +1,14 @@
+--1 
+CREATE SEQUENCE seq_tp
+INCREMENT BY 1
+START WITH 121;
+BEGIN
+
+--2
+
+CREATE PROCEDURE sp_insert_ligne_commande(p_commande_id INT, p_produit_id INT,p_quantit number)
+is v_prix_total NUMBER
+BEGIN 
+SELECT p.prix_unitaire*lc.p_quantite into v_prix_total FROM Produit p, Ligne_commande lc WHERE p.id=p_produit_id
+INSERT INTO Ligne_commande values (seq_t.NEXT, p_commande_id,
+p_produit_id, p_quantite,v_prix_total)

TP_DEV3.2/Arbres/Node.java

@@ -0,0 +1,50 @@
+import java.io.File;
+import java.util.ArrayList;
+import java.util.List;
+
+
+public class Node {
+
+    String name;
+    List<Node> children = new ArrayList<>();
+
+    public Node(String name){
+        this.name = name;
+    }
+
+    public void addChild(Node child){
+        children.add(child);
+    }
+
+    public void afficher(String indent){
+        System.out.println(indent + name);
+        for(Node c : children){
+            c.afficher(indent + "  "); // indentation augmentée
+        }
+    }
+
+    public static Node build(File f){
+        Node n = new Node(f.getName());
+        File[] list = f.listFiles();
+
+        if(list != null){
+            for(File child : list){
+                n.addChild(build(child)); // récursion OK
+            }
+        }
+
+        return n;
+    }
+
+    public static void main(String[] args) {
+
+        if(args.length != 1){
+            System.out.println("Usage : java Node <repertoire>");
+            return; // éviter un crash
+        }
+
+        File fichier = new File(args[0]);
+        Node tree = build(fichier);
+        tree.afficher("");
+    }
+}

TP_DEV3.2/Arbres/Prefixe.java

@@ -0,0 +1,39 @@
+public class Prefixe {
+
+
+    String value;
+    Prefixe left;
+    Prefixe right;
+
+public Prefixe(String v) { 
+        this.value = v; 
+    }
+
+    public boolean isOperator() {
+        return "+-*/".contains(value);
+ }
+
+public static int index = 0;
+
+    public static Prefixe build(String[] t) {
+        String token = t[index++];
+        Prefixe p = new Prefixe(token);
+
+        if (p.isOperator()) {
+            p.left = build(t);
+            p.right = build(t);
+        }
+        return p;
+    }
+
+
+
+
+
+
+
+
+
+
+
+}

TP_DEV3.2/Arbres/Repertoires.java

@@ -27,7 +27,7 @@ public afficher(String nom){
 
     for(Node c : children){
 
-        c.print(nom+"");
+        c.print(nom+" ");
 
     }
 

TP_DEV3.2/Repertoires.java

@@ -1,73 +0,0 @@
-import java.io.File;
-import java.util.ArrayList;
-import java.util.List;
-
-
-public class Repertoires {
-
-
-String name;
-List<Node> children = new ArrayList<>();
-
-public Node(String name){
-
-    this.name=name;
-
-}
-
-public addChild(Node child){
-
-children.add(child);
-
-}
-
-public afficher(String nom){
-
-    System.out.println(nom+name);
-
-    for(Node c : children){
-
-        c.print(nom+"");
-
-    }
-
-
-}
-public static Node build(File f){
-
-Node n = new Node(file.getName());
-File[] list = f.listFiles();
-if(list!=null){
-
-for(File child : list){
-
-    n.addChild(build(child));
-}
-
-}
-
-return n;
-
-
-
-}
-
-
-public static void main(String[] args) {
-    
-File fichier = New File(args[0]);
-Node tree = build(Dictionnaire);
-
-tree.afficher("");
-
-
-
-
-
-}
-
-
-
-
-
-}

TP_SCR3.2/TP02/TP02-reponses.txt

@@ -0,0 +1,8 @@
+TP02-
+
+I-
+
+1) Les adresses réseaux correspondantes sont: 
+-> 45.45.40.0/21 
+-> 62.62.32.0/19
+-> 37.37.36.0/22

TP_SCR3.2/TP02/with-routers.imn

@@ -0,0 +1,455 @@
+node n0 {
+    type pc
+    network-config {
+	hostname pc1
+	!
+	interface eth0
+	 ip address 172.16.1.1/24
+	 mac address 42:00:aa:00:00:00
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	ip route 0.0.0.0/0 172.16.1.253
+	!
+    }
+    canvas c0
+    iconcoords {24 288}
+    labelcoords {24 319}
+    interface-peer {eth0 n3}
+}
+
+node n1 {
+    type pc
+    network-config {
+	hostname pc2
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:06
+	 ip address 172.16.2.2/24
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	ip route 0.0.0.0/0 172.16.2.0
+	!
+    }
+    canvas c0
+    iconcoords {336 432}
+    labelcoords {336 463}
+    interface-peer {eth0 n4}
+}
+
+node n2 {
+    type pc
+    network-config {
+	hostname pc3
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:07
+	 ip address 172.16.3.3/24
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {864 192}
+    labelcoords {864 223}
+    interface-peer {eth0 n5}
+}
+
+node n3 {
+    type lanswitch
+    network-config {
+	hostname switch1
+	!
+    }
+    canvas c0
+    iconcoords {168 24}
+    labelcoords {168 47}
+    interface-peer {e0 n0}
+    interface-peer {e1 n6}
+}
+
+node n4 {
+    type lanswitch
+    network-config {
+	hostname switch2
+	!
+    }
+    canvas c0
+    iconcoords {480 48}
+    labelcoords {480 71}
+    interface-peer {e0 n1}
+    interface-peer {e1 n6}
+    interface-peer {e2 n7}
+}
+
+node n5 {
+    type lanswitch
+    network-config {
+	hostname switch3
+	!
+    }
+    canvas c0
+    iconcoords {768 24}
+    labelcoords {768 47}
+    interface-peer {e0 n2}
+    interface-peer {e1 n7}
+}
+
+node n6 {
+    type host
+    network-config {
+	hostname GW1
+	!
+	interface eth1
+	 mac address 42:00:aa:00:00:03
+	 ip address 172.16.2.253/24
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:02
+	 ip address 172.16.1.253/24
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	ip route 0.0.0.0/0 172.16.2.254
+	!
+    }
+    canvas c0
+    iconcoords {264 288}
+    labelcoords {264 324}
+    interface-peer {eth0 n3}
+    interface-peer {eth1 n4}
+    custom-configs {
+        custom-config-id default {
+            custom-command /bin/sh
+            config {
+                ip addr add 127.0.0.1/8 dev lo0
+                ip addr add 172.16.1.254/24 dev eth0
+                ip addr add 172.16.2.254/24 dev eth1
+                ip -6 addr add ::1/128 dev lo0
+                
+                ip route append 0.0.0.0/0 via 172.16.2.252
+                iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.16.2.253
+                iptables -t filter -A FORWARD -d 172.16.3.0/24 -j DROP  
+                rpcbind
+                inetd
+                
+            }
+        }
+    }
+    custom-enabled true
+    custom-selected default
+}
+
+node n7 {
+    type host
+    network-config {
+	hostname GW2
+	!
+	interface eth2
+	 mac address 42:00:aa:00:00:05
+	 ip address 45.45.45.254/24
+	!
+	interface eth1
+	 mac address 42:00:aa:00:00:04
+	 ip address 172.16.3.254/24
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:01
+	 ip address 172.16.2.254/24
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    canvas c0
+    iconcoords {624 240}
+    labelcoords {624 276}
+    interface-peer {eth0 n4}
+    interface-peer {eth1 n5}
+    custom-configs {
+        custom-config-id default {
+            custom-command /bin/sh
+            config {
+                ip addr add 127.0.0.1/8 dev lo0
+                ip addr add 172.16.2.252/24 dev eth0
+                ip addr add 172.16.3.251/24 dev eth1
+                ip addr add 10.0.0.250/8 dev eth2
+                ip -6 addr add ::1/128 dev lo0
+                
+                iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.16.3.254
+                iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 45.45.45.254
+                
+                ip route add 0.0.0.0/0 via 10.0.0.1
+                
+                rpcbind
+                inetd
+                
+            }
+        }
+    }
+    custom-enabled true
+    interface-peer {eth2 n8}
+    custom-selected default
+}
+
+node n9 {
+    type pc
+    network-config {
+	hostname pc
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:0d
+	 ip address 37.37.37.1/22
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	ip route 37.37.36.0/22 37.37.37.254
+	!
+    }
+    canvas c0
+    iconcoords {24 576}
+    labelcoords {24 607}
+    interface-peer {eth0 n13}
+}
+
+node n8 {
+    type lanswitch
+    network-config {
+	hostname switch4
+	!
+    }
+    canvas c0
+    iconcoords {744 528}
+    labelcoords {744 551}
+    interface-peer {e0 n7}
+    interface-peer {e1 n10}
+    interface-peer {e2 n11}
+    interface-peer {e3 n12}
+}
+
+node n10 {
+    type host
+    network-config {
+	hostname host1
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:08
+	 ip address 45.45.45.1/21
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {792 264}
+    labelcoords {792 300}
+    interface-peer {eth0 n8}
+}
+
+node n11 {
+    type host
+    network-config {
+	hostname host2
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:09
+	 ip address 45.45.45.2/21
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {888 384}
+    labelcoords {888 420}
+    interface-peer {eth0 n8}
+}
+
+node n12 {
+    type router
+    model quagga
+    network-config {
+	hostname router1
+	!
+	interface eth1
+	 mac address 42:00:aa:00:00:0c
+	 ip address 62.62.62.253/19
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:0a
+	 ip address 45.45.45.253/21
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	router rip
+	 redistribute static
+	 redistribute connected
+	 redistribute ospf
+	 network 0.0.0.0/0
+	!
+	router ripng
+	 redistribute static
+	 redistribute connected
+	 redistribute ospf6
+	 network ::/0
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {576 576}
+    labelcoords {576 601}
+    interface-peer {eth0 n8}
+    interface-peer {eth1 n13}
+}
+
+node n13 {
+    type router
+    model quagga
+    network-config {
+	hostname router2
+	!
+	interface eth1
+	 mac address 42:00:aa:00:00:0e
+	 ip address 37.37.37.254/22
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:0b
+	 ip address 62.62.62.254/19
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+	router rip
+	 redistribute static
+	 redistribute connected
+	 redistribute ospf
+	 network 0.0.0.0/0
+	!
+	router ripng
+	 redistribute static
+	 redistribute connected
+	 redistribute ospf6
+	 network ::/0
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {288 576}
+    labelcoords {288 601}
+    interface-peer {eth0 n12}
+    interface-peer {eth1 n9}
+}
+
+link l0 {
+    nodes {n3 n0}
+    bandwidth 0
+}
+
+link l1 {
+    nodes {n4 n1}
+    bandwidth 0
+}
+
+link l2 {
+    nodes {n6 n3}
+    bandwidth 0
+}
+
+link l3 {
+    nodes {n6 n4}
+    bandwidth 0
+}
+
+link l4 {
+    nodes {n5 n2}
+    bandwidth 0
+}
+
+link l5 {
+    nodes {n7 n4}
+    bandwidth 0
+}
+
+link l6 {
+    nodes {n7 n5}
+    bandwidth 0
+}
+
+link l7 {
+    nodes {n8 n7}
+    bandwidth 0
+}
+
+link l8 {
+    nodes {n10 n8}
+    bandwidth 0
+}
+
+link l9 {
+    nodes {n11 n8}
+    bandwidth 0
+}
+
+link l10 {
+    nodes {n12 n8}
+    bandwidth 0
+}
+
+link l11 {
+    nodes {n13 n12}
+    bandwidth 0
+}
+
+link l12 {
+    nodes {n9 n13}
+    bandwidth 0
+}
+
+canvas c0 {
+    name {Canvas0}
+}
+
+option show {
+    interface_names yes
+    ip_addresses yes
+    ipv6_addresses yes
+    node_labels yes
+    link_labels yes
+    background_images no
+    annotations yes
+    hostsAutoAssign no
+    grid yes
+    iconSize normal
+    zoom 1.0
+}
+

TP_SCR3.2/TP03/dhcp-serv.imn

@@ -0,0 +1,215 @@
+node n0 {
+    type pc
+    network-config {
+	hostname pc1-1
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:01
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {144 384}
+    labelcoords {144 415}
+    interface-peer {eth0 n2}
+}
+
+node n1 {
+    type pc
+    network-config {
+	hostname pc1-2
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:02
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {288 384}
+    labelcoords {288 415}
+    interface-peer {eth0 n2}
+}
+
+node n2 {
+    type hub
+    network-config {
+	hostname hub1
+	!
+    }
+    canvas c0
+    iconcoords {216 240}
+    labelcoords {216 261}
+    interface-peer {e0 n3}
+    interface-peer {e1 n0}
+    interface-peer {e2 n1}
+    interface-peer {e3 n4}
+}
+
+node n3 {
+    type host
+    network-config {
+	hostname DHCPsrv
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:00
+	 ip address 192.168.10.10/20
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {72 96}
+    labelcoords {72 132}
+    interface-peer {eth0 n2}
+}
+
+node n4 {
+    type host
+    network-config {
+	hostname GW
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:03
+	 ip address 192.168.10.254/20
+	!
+	interface eth1
+	 mac address 42:00:aa:00:00:04
+	 ip address 172.16.2.254/24
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {456 96}
+    labelcoords {456 132}
+    interface-peer {eth0 n2}
+    interface-peer {eth1 n5}
+}
+
+node n5 {
+    type hub
+    network-config {
+	hostname hub2
+	!
+    }
+    canvas c0
+    iconcoords {624 192}
+    labelcoords {624 213}
+    interface-peer {e0 n4}
+    interface-peer {e1 n6}
+    interface-peer {e2 n7}
+}
+
+node n6 {
+    type pc
+    network-config {
+	hostname pc2-1
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:05
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {504 360}
+    labelcoords {504 391}
+    interface-peer {eth0 n5}
+}
+
+node n7 {
+    type pc
+    network-config {
+	hostname pc2-2
+	!
+	interface eth0
+	 mac address 42:00:aa:00:00:06
+	!
+	interface lo0
+	 type lo
+	 ip address 127.0.0.1/8
+	 ipv6 address ::1/128
+	!
+    }
+    auto_default_routes enabled
+    canvas c0
+    iconcoords {696 360}
+    labelcoords {696 391}
+    interface-peer {eth0 n5}
+}
+
+link l0 {
+    nodes {n2 n3}
+    bandwidth 0
+}
+
+link l1 {
+    nodes {n0 n2}
+    bandwidth 0
+}
+
+link l2 {
+    nodes {n1 n2}
+    bandwidth 0
+}
+
+link l3 {
+    nodes {n4 n2}
+    bandwidth 0
+}
+
+link l4 {
+    nodes {n5 n4}
+    bandwidth 0
+}
+
+link l5 {
+    nodes {n6 n5}
+    bandwidth 0
+}
+
+link l6 {
+    nodes {n7 n5}
+    bandwidth 0
+}
+
+canvas c0 {
+    name {Canvas0}
+}
+
+option show {
+    interface_names yes
+    ip_addresses yes
+    ipv6_addresses yes
+    node_labels yes
+    link_labels yes
+    background_images no
+    annotations yes
+    hostsAutoAssign no
+    grid yes
+    iconSize normal
+    zoom 1.0
+}
+

TP_valarcher/Yolou_4/Prompt_reponse.txt

@@ -0,0 +1,146 @@
+(Prompt et reéponses fait sur Chat GPT - modele 5.1)
+
+
+
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
+
+Il m'a tout d'abord généré sa reponse : 
+"Nouvelle fonctionnalité choisie (INVENTÉE) :
+« Le système envoie un email quand un utilisateur modifie son adresse. »
+Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
+
+Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
+
+Contexte 1 : Application de livraison (ex : Uber Eats)
+
+Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
+Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
+ Donc dans ce contexte, envoyer un email = EF (fonction métier).
+
+ Pourquoi ?
+
+Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
+
+ Contexte 2 : Réseau social (ex : Instagram)
+
+Dans un réseau social, changer son adresse n’a aucun impact métier important.
+L’envoi d’un email sert juste à améliorer la sécurité du compte.
+Donc ici, c’est une ENF (sécurité).
+
+ Pourquoi ?
+
+Parce que ce n’est pas une vraie fonctionnalité métier.
+L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
+
+Q1-b – Rédaction DES EXIGENCES pour chaque contexte
+Tu dois réécrire une exigence adaptée au contexte.
+Une pour le contexte 1, une pour le contexte 2.
+
+Exigence pour le contexte 1 (livraison → EF)
+« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
+Ça décrit bien une action métier → EF.
+
+Q1-c – Impact sur le BACKLOG selon EF ou ENF
+Tu expliques comment EF/ENF affecte l’organisation du travail.
+
+Si EF → devient une User Story prioritaire
+Dans le contexte de livraison :
+L’envoi de mail devient une vraie User Story :
+
+“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
+
+
+Elle sera priorisée car elle empêche les erreurs du métier.
+Elle peut être découpée en sous-stories : format du mail, contenu, timing…
+
+Plus de stories → backlog plus granularisé.
+Si ENF → devient un critère d’acceptation
+Dans le contexte du réseau social :
+Pas une User Story.
+
+
+C’est un critère d’acceptation de la story : “Gérer son compte”.
+C’est moins prioritaire.
+
+
+On peut le mettre dans un sprint plus tard.
+Moins de stories → backlog plus simple.
+
+"
+
+-------
+
+Q2 – Refonte d’un backlog non INVEST
+
+PARTIE 1 –  Prompt que j’ai utilisé
+« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
+
+PARTIE 2 – Réponse donnée par ChatGPT
+
+Exemple :
+Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres stories (refonte complète)
+– N : contenu flou, non négociable
+– V : valeur métier faible
+– E : impossible à estimer (« moderne » est subjectif)
+– S : trop grande
+– T : non testable
+
+Backlog corrigé :
+
+US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
+US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
+US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
+
+-------
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+PARTIE 1 – Prompt que j'ai utilisé
+« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple de processus métier :
+
+L’utilisateur consulte la fiche d’un produit.
+Le système affiche le stock disponible.
+Si le produit est en rupture, le système bloque l’ajout au panier.
+Le système propose une alerte de remise en stock.
+Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
+Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
+
+
+Exemple de compléments au DCD :
+– Classe : AlerteStock, attributs : dateInscription, canalNotification.
+– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
+Exemple Given/When/Then :
+Given un produit en rupture,
+When l’utilisateur active l’alerte,
+Then il reçoit une notification lorsque le produit revient en stock.
+
+-------
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
+
+« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple :
+
+User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
+Cas d’utilisation possibles :
+– Saisir ses informations de paiement
+– Confirmer le paiement
+– Obtenir une confirmation de commande
+Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
+Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
+

TP_valarcher/Yolou_4/Yolou_4.txt

@@ -0,0 +1,203 @@
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
+
+Q1-a :
+
+Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
+Changer son mot de passe ne fait pas partie du parcours pédagogique.
+C’est une exigence de sécurité, donc ENF.
+
+Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
+ Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
+La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
+
+Q1-b et Q1-c
+
+Contexte 1 : Application éducative (type Duolingo)
+Classification : ENF (exigence non-fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte éducatif
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
+Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
+
+Q1-c – Impact sur le backlog (application éducative)
+Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
+
+Contexte 2 : Plateforme d’investissement / trading
+Classification : EF (exigence fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte investissement/trading
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
+Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
+
+Q1-c – Impact sur le backlog (plateforme d’investissement)
+Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
+
+--------------------------
+
+Q2 – Refonte d’un backlog non INVEST
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q2-a – Début de réponse
+Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
+
+Q2-b – Début de réponse
+Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
+
+Q2-c – Début de réponse
+Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
+
+En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
+
+Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q2-a – Identification des problèmes dans les User Stories
+
+US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres fonctionnalités
+– S : trop large (« complet », « global »)
+– T : non testable sans préciser les informations attendues
+– E : non estimable, périmètre flou
+– V : valeur métier non explicite
+
+US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
+
+Problèmes INVEST :
+
+– V : valeur métier non définie
+– E : non estimable (« moderne » est subjectif)
+– T : non testable
+– S : trop large (design, navigation, composants)
+
+US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
+
+Problèmes INVEST :
+
+– S : trop grande (« tout le système »)
+– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
+– T : impossible à tester
+– E : impossible à estimer, périmètre trop vaste
+
+Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
+
+US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
+US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
+US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
+US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
+US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
+US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
+
+Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
+
+Story X – US-A : « Consulter la liste de mes tâches du jour »
+
+Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
+Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
+
+Story Y – US-F : « Désactiver un compte utilisateur »
+
+Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
+Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q3-a – Début de réponse
+
+Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
+
+Q3-b – Début de réponse
+
+Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
+
+Q3-c – Début de réponse
+
+Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
+
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q3-a – Rédaction du processus métier (au moins 8 étapes)
+
+Le client consulte la page d’un produit dans la boutique en ligne.
+Le système vérifie le niveau de stock du produit.
+Si le stock est positif, le système permet l’ajout normal au panier.
+Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
+Le système propose alors au client de s’inscrire à une alerte de remise en stock.
+Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
+En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
+Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
+Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
+
+
+Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
+
+Nouvelles classes :
+
+– AlerteRuptureStock
+– CommandeFournisseur
+
+Nouveaux attributs pertinents :
+
+– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
+– AlerteRuptureStock : dateInscription, canalNotification
+– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
+
+Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
+
+Q3-c – Scénario de test d’acceptation (Given / When / Then)
+
+Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
+When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
+Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q4-a – Début de réponse
+
+Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
+
+Q4-b – Début de réponse
+
+Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
+
+Q4-c – Début de réponse
+
+Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) : 
+
+Q4-a – Exemple de User Story et cas d’utilisation dérivés
+
+User Story choisie :
+
+« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
+Cas d’utilisation dérivés :
+– Consulter un produit et l’ajouter au panier
+– Modifier le contenu du panier
+– Saisir une adresse de livraison
+– Choisir un mode de livraison
+– Sélectionner un moyen de paiement
+– Valider la commande
+– Recevoir un récapitulatif de commande
+
+Q4-b – Risques d’un projet qui ne repose que sur des User Stories
+
+Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
+
+Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
+
+Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
+
+
+
+
+

TP_valarcher/controle_tp_191125/Prompt_reponse.txt

@@ -0,0 +1,146 @@
+(Prompt et reéponses fait sur Chat GPT - modele 5.1)
+
+
+
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
+
+Il m'a tout d'abord généré sa reponse : 
+"Nouvelle fonctionnalité choisie (INVENTÉE) :
+« Le système envoie un email quand un utilisateur modifie son adresse. »
+Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
+
+Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
+
+Contexte 1 : Application de livraison (ex : Uber Eats)
+
+Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
+Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
+ Donc dans ce contexte, envoyer un email = EF (fonction métier).
+
+ Pourquoi ?
+
+Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
+
+ Contexte 2 : Réseau social (ex : Instagram)
+
+Dans un réseau social, changer son adresse n’a aucun impact métier important.
+L’envoi d’un email sert juste à améliorer la sécurité du compte.
+Donc ici, c’est une ENF (sécurité).
+
+ Pourquoi ?
+
+Parce que ce n’est pas une vraie fonctionnalité métier.
+L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
+
+Q1-b – Rédaction DES EXIGENCES pour chaque contexte
+Tu dois réécrire une exigence adaptée au contexte.
+Une pour le contexte 1, une pour le contexte 2.
+
+Exigence pour le contexte 1 (livraison → EF)
+« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
+Ça décrit bien une action métier → EF.
+
+Q1-c – Impact sur le BACKLOG selon EF ou ENF
+Tu expliques comment EF/ENF affecte l’organisation du travail.
+
+Si EF → devient une User Story prioritaire
+Dans le contexte de livraison :
+L’envoi de mail devient une vraie User Story :
+
+“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
+
+
+Elle sera priorisée car elle empêche les erreurs du métier.
+Elle peut être découpée en sous-stories : format du mail, contenu, timing…
+
+Plus de stories → backlog plus granularisé.
+Si ENF → devient un critère d’acceptation
+Dans le contexte du réseau social :
+Pas une User Story.
+
+
+C’est un critère d’acceptation de la story : “Gérer son compte”.
+C’est moins prioritaire.
+
+
+On peut le mettre dans un sprint plus tard.
+Moins de stories → backlog plus simple.
+
+"
+
+-------
+
+Q2 – Refonte d’un backlog non INVEST
+
+PARTIE 1 –  Prompt que j’ai utilisé
+« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
+
+PARTIE 2 – Réponse donnée par ChatGPT
+
+Exemple :
+Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres stories (refonte complète)
+– N : contenu flou, non négociable
+– V : valeur métier faible
+– E : impossible à estimer (« moderne » est subjectif)
+– S : trop grande
+– T : non testable
+
+Backlog corrigé :
+
+US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
+US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
+US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
+
+-------
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+PARTIE 1 – Prompt que j'ai utilisé
+« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple de processus métier :
+
+L’utilisateur consulte la fiche d’un produit.
+Le système affiche le stock disponible.
+Si le produit est en rupture, le système bloque l’ajout au panier.
+Le système propose une alerte de remise en stock.
+Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
+Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
+
+
+Exemple de compléments au DCD :
+– Classe : AlerteStock, attributs : dateInscription, canalNotification.
+– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
+Exemple Given/When/Then :
+Given un produit en rupture,
+When l’utilisateur active l’alerte,
+Then il reçoit une notification lorsque le produit revient en stock.
+
+-------
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
+
+« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple :
+
+User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
+Cas d’utilisation possibles :
+– Saisir ses informations de paiement
+– Confirmer le paiement
+– Obtenir une confirmation de commande
+Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
+Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
+

TP_valarcher/controle_tp_191125/Yolou_4.txt

@@ -0,0 +1,203 @@
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
+
+Q1-a :
+
+Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
+Changer son mot de passe ne fait pas partie du parcours pédagogique.
+C’est une exigence de sécurité, donc ENF.
+
+Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
+ Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
+La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
+
+Q1-b et Q1-c
+
+Contexte 1 : Application éducative (type Duolingo)
+Classification : ENF (exigence non-fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte éducatif
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
+Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
+
+Q1-c – Impact sur le backlog (application éducative)
+Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
+
+Contexte 2 : Plateforme d’investissement / trading
+Classification : EF (exigence fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte investissement/trading
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
+Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
+
+Q1-c – Impact sur le backlog (plateforme d’investissement)
+Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
+
+--------------------------
+
+Q2 – Refonte d’un backlog non INVEST
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q2-a – Début de réponse
+Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
+
+Q2-b – Début de réponse
+Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
+
+Q2-c – Début de réponse
+Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
+
+En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
+
+Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q2-a – Identification des problèmes dans les User Stories
+
+US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres fonctionnalités
+– S : trop large (« complet », « global »)
+– T : non testable sans préciser les informations attendues
+– E : non estimable, périmètre flou
+– V : valeur métier non explicite
+
+US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
+
+Problèmes INVEST :
+
+– V : valeur métier non définie
+– E : non estimable (« moderne » est subjectif)
+– T : non testable
+– S : trop large (design, navigation, composants)
+
+US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
+
+Problèmes INVEST :
+
+– S : trop grande (« tout le système »)
+– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
+– T : impossible à tester
+– E : impossible à estimer, périmètre trop vaste
+
+Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
+
+US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
+US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
+US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
+US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
+US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
+US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
+
+Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
+
+Story X – US-A : « Consulter la liste de mes tâches du jour »
+
+Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
+Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
+
+Story Y – US-F : « Désactiver un compte utilisateur »
+
+Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
+Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q3-a – Début de réponse
+
+Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
+
+Q3-b – Début de réponse
+
+Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
+
+Q3-c – Début de réponse
+
+Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
+
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q3-a – Rédaction du processus métier (au moins 8 étapes)
+
+Le client consulte la page d’un produit dans la boutique en ligne.
+Le système vérifie le niveau de stock du produit.
+Si le stock est positif, le système permet l’ajout normal au panier.
+Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
+Le système propose alors au client de s’inscrire à une alerte de remise en stock.
+Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
+En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
+Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
+Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
+
+
+Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
+
+Nouvelles classes :
+
+– AlerteRuptureStock
+– CommandeFournisseur
+
+Nouveaux attributs pertinents :
+
+– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
+– AlerteRuptureStock : dateInscription, canalNotification
+– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
+
+Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
+
+Q3-c – Scénario de test d’acceptation (Given / When / Then)
+
+Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
+When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
+Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q4-a – Début de réponse
+
+Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
+
+Q4-b – Début de réponse
+
+Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
+
+Q4-c – Début de réponse
+
+Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) : 
+
+Q4-a – Exemple de User Story et cas d’utilisation dérivés
+
+User Story choisie :
+
+« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
+Cas d’utilisation dérivés :
+– Consulter un produit et l’ajouter au panier
+– Modifier le contenu du panier
+– Saisir une adresse de livraison
+– Choisir un mode de livraison
+– Sélectionner un moyen de paiement
+– Valider la commande
+– Recevoir un récapitulatif de commande
+
+Q4-b – Risques d’un projet qui ne repose que sur des User Stories
+
+Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
+
+Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
+
+Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
+
+
+
+
+

TP_valarcher/controle_tp_191125/Yolou_4/Prompt_reponse.txt

@@ -0,0 +1,146 @@
+(Prompt et reéponses fait sur Chat GPT - modele 5.1)
+
+
+
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
+
+Il m'a tout d'abord généré sa reponse : 
+"Nouvelle fonctionnalité choisie (INVENTÉE) :
+« Le système envoie un email quand un utilisateur modifie son adresse. »
+Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
+
+Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
+
+Contexte 1 : Application de livraison (ex : Uber Eats)
+
+Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
+Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
+ Donc dans ce contexte, envoyer un email = EF (fonction métier).
+
+ Pourquoi ?
+
+Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
+
+ Contexte 2 : Réseau social (ex : Instagram)
+
+Dans un réseau social, changer son adresse n’a aucun impact métier important.
+L’envoi d’un email sert juste à améliorer la sécurité du compte.
+Donc ici, c’est une ENF (sécurité).
+
+ Pourquoi ?
+
+Parce que ce n’est pas une vraie fonctionnalité métier.
+L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
+
+Q1-b – Rédaction DES EXIGENCES pour chaque contexte
+Tu dois réécrire une exigence adaptée au contexte.
+Une pour le contexte 1, une pour le contexte 2.
+
+Exigence pour le contexte 1 (livraison → EF)
+« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
+Ça décrit bien une action métier → EF.
+
+Q1-c – Impact sur le BACKLOG selon EF ou ENF
+Tu expliques comment EF/ENF affecte l’organisation du travail.
+
+Si EF → devient une User Story prioritaire
+Dans le contexte de livraison :
+L’envoi de mail devient une vraie User Story :
+
+“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
+
+
+Elle sera priorisée car elle empêche les erreurs du métier.
+Elle peut être découpée en sous-stories : format du mail, contenu, timing…
+
+Plus de stories → backlog plus granularisé.
+Si ENF → devient un critère d’acceptation
+Dans le contexte du réseau social :
+Pas une User Story.
+
+
+C’est un critère d’acceptation de la story : “Gérer son compte”.
+C’est moins prioritaire.
+
+
+On peut le mettre dans un sprint plus tard.
+Moins de stories → backlog plus simple.
+
+"
+
+-------
+
+Q2 – Refonte d’un backlog non INVEST
+
+PARTIE 1 –  Prompt que j’ai utilisé
+« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
+
+PARTIE 2 – Réponse donnée par ChatGPT
+
+Exemple :
+Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres stories (refonte complète)
+– N : contenu flou, non négociable
+– V : valeur métier faible
+– E : impossible à estimer (« moderne » est subjectif)
+– S : trop grande
+– T : non testable
+
+Backlog corrigé :
+
+US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
+US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
+US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
+
+-------
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+PARTIE 1 – Prompt que j'ai utilisé
+« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple de processus métier :
+
+L’utilisateur consulte la fiche d’un produit.
+Le système affiche le stock disponible.
+Si le produit est en rupture, le système bloque l’ajout au panier.
+Le système propose une alerte de remise en stock.
+Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
+Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
+
+
+Exemple de compléments au DCD :
+– Classe : AlerteStock, attributs : dateInscription, canalNotification.
+– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
+Exemple Given/When/Then :
+Given un produit en rupture,
+When l’utilisateur active l’alerte,
+Then il reçoit une notification lorsque le produit revient en stock.
+
+-------
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
+
+« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
+
+PARTIE 2 – Exemple de réponse donnée par ChatGPT
+
+Exemple :
+
+User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
+Cas d’utilisation possibles :
+– Saisir ses informations de paiement
+– Confirmer le paiement
+– Obtenir une confirmation de commande
+Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
+Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
+

TP_valarcher/controle_tp_191125/Yolou_4/Yolou_4.txt

@@ -0,0 +1,203 @@
+Q1 Frontière EF/ENF dépendante du contexte 
+
+Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
+
+Q1-a :
+
+Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
+Changer son mot de passe ne fait pas partie du parcours pédagogique.
+C’est une exigence de sécurité, donc ENF.
+
+Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
+ Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
+La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
+
+Q1-b et Q1-c
+
+Contexte 1 : Application éducative (type Duolingo)
+Classification : ENF (exigence non-fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte éducatif
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
+Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
+
+Q1-c – Impact sur le backlog (application éducative)
+Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
+
+Contexte 2 : Plateforme d’investissement / trading
+Classification : EF (exigence fonctionnelle)
+
+Q1-b – Exigence adaptée au contexte investissement/trading
+« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
+Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
+
+Q1-c – Impact sur le backlog (plateforme d’investissement)
+Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
+
+--------------------------
+
+Q2 – Refonte d’un backlog non INVEST
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q2-a – Début de réponse
+Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
+
+Q2-b – Début de réponse
+Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
+
+Q2-c – Début de réponse
+Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
+
+En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
+
+Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q2-a – Identification des problèmes dans les User Stories
+
+US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
+
+Problèmes INVEST :
+
+– I : dépend d’autres fonctionnalités
+– S : trop large (« complet », « global »)
+– T : non testable sans préciser les informations attendues
+– E : non estimable, périmètre flou
+– V : valeur métier non explicite
+
+US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
+
+Problèmes INVEST :
+
+– V : valeur métier non définie
+– E : non estimable (« moderne » est subjectif)
+– T : non testable
+– S : trop large (design, navigation, composants)
+
+US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
+
+Problèmes INVEST :
+
+– S : trop grande (« tout le système »)
+– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
+– T : impossible à tester
+– E : impossible à estimer, périmètre trop vaste
+
+Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
+
+US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
+US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
+US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
+US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
+US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
+US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
+
+Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
+
+Story X – US-A : « Consulter la liste de mes tâches du jour »
+
+Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
+Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
+
+Story Y – US-F : « Désactiver un compte utilisateur »
+
+Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
+Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
+
+Q3 – Gestion des ruptures de stock dans une boutique en ligne
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q3-a – Début de réponse
+
+Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
+
+Q3-b – Début de réponse
+
+Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
+
+Q3-c – Début de réponse
+
+Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
+
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1): 
+
+Q3-a – Rédaction du processus métier (au moins 8 étapes)
+
+Le client consulte la page d’un produit dans la boutique en ligne.
+Le système vérifie le niveau de stock du produit.
+Si le stock est positif, le système permet l’ajout normal au panier.
+Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
+Le système propose alors au client de s’inscrire à une alerte de remise en stock.
+Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
+En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
+Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
+Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
+
+
+Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
+
+Nouvelles classes :
+
+– AlerteRuptureStock
+– CommandeFournisseur
+
+Nouveaux attributs pertinents :
+
+– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
+– AlerteRuptureStock : dateInscription, canalNotification
+– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
+
+Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
+
+Q3-c – Scénario de test d’acceptation (Given / When / Then)
+
+Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
+When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
+Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
+
+Q4 – Complémentarité entre User Stories et Cas d’utilisation
+
+Début de réponse que j’ai écrit que j'ai commencé à rédiger : 
+
+Q4-a – Début de réponse
+
+Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
+
+Q4-b – Début de réponse
+
+Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
+
+Q4-c – Début de réponse
+
+Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
+
+Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) : 
+
+Q4-a – Exemple de User Story et cas d’utilisation dérivés
+
+User Story choisie :
+
+« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
+Cas d’utilisation dérivés :
+– Consulter un produit et l’ajouter au panier
+– Modifier le contenu du panier
+– Saisir une adresse de livraison
+– Choisir un mode de livraison
+– Sélectionner un moyen de paiement
+– Valider la commande
+– Recevoir un récapitulatif de commande
+
+Q4-b – Risques d’un projet qui ne repose que sur des User Stories
+
+Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
+
+Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
+
+Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
+
+
+
+
+