Discussion :

[bangaromaric]

Bonjour tout le monde,
j'ai besoin de conseil sur la conception du MCD que j'ai posté en pièce jointe il y a l'image et le fichier source, j'utilise le logiciel Jmerise de JFreeSoft.
C'est la modélisation d'une application de gestion de flotte automobile qui a pour mission d'assurer de façon concrète et précise l'ensemble des tâches de gestion d'un
parc automobile. Il vous permet d'enregistrer, de gérer et de consulter rapidement toute information relative à votre parc automobile.
Le client à la possibilité de faire une réservation ou de directement louer une voiture, le client à la possibilité de conduire lui même, ou de prendre un chauffeur,
une location fait l'objet d'une facture, lorsqu'une facture est supprimée elle inscrit toutes ses informations dans l'entité historique.
voilà j'ai des doutes sur les relations entre les entités (factures, client, chauffeur, réservations, historique, vehicules).
Je sollicite votre aide. merci d'avance
Je suis novice sur ce site

[fsmrel]

Bonsoir Leromantiqueroma,


L’association CONDUIRE à laquelle participent les entités-types CLIENT, VEHICULE et CHAUFFEUR est a priori inutile. En effet, quand le client Raoul effectue une location, on peut supposer que, outre les données concernant ce client, on enregistre dans la facture (ou autre moyen de mémorisation) les données identifiant le véhicule loué. Quant au chauffeur, l’association INCLURE connectant les entités-types FACTURE et CHAUFFEUR devrait suffire pour savoir de qui il s'agit. En tout cas, cette association CONDUIRE nous apprend seulement que tel chauffeur a conduit tel client dans telle voiture, ce qui est maigre comme information : elle ne dit pas à quelle date.

L’association PAYER doit connecter uniquement les entités-types FACTURE et CLIENT. L’entité-type RESERVATION doit être directement rattachée à l’entité-type FACTURE, car connaissant la facture, on connaît le client qui a réservé : inutile qu’on apprenne cela une fois supplémentaire.

L’entité-type FACTURE est porteuse des attributs suivants : datel, dateRetour, nbrJours. Si nbrJours est égal à dateRetour – datel, il y a une redondance calculable, auquel cas on élimine soit dateRetour soit nbrJours.


Entité-type HISTORIQUE : vous historisez les données essentielles permettant de reconstituer chaque facture, soit. Manifestement, la patte connectant cette entité-type et l’association EXISTER doit être porteuse d’une cardinalité 1,1, sinon une ligne HISTORIQUE peut concerner plusieurs factures de différents clients : ça n’est pas viable...

[bangaromaric]

Bonjour fsmrel merci de m'avoir répondu, j'ai pris note et fait des modifications
sur le mcd. L'entité réservation a été déplacé et j'ai du mal à comprendre cette logique si vous pouvez me donner plus d'éclaircissement,
et ses attributs doivent aussi changer?

[fsmrel]

Bonsoir Leromantiqueroma,

L'entité réservation a été déplacé et j'ai du mal à comprendre cette logique.

Il faut se souvenir de la façon dont on lit une association. Ainsi, dans votre 1er MCD, l’association PAYER est ternaire et se lit ainsi :

— Chaque client participe au moins une fois à l’association ;

— Chaque facture participe au moins et au plus une fois à l’association ;

— Une réservation participe facultativement et au plus une fois à l’association.

Mais, par définition, chaque occurrence (instance) de l’association contient une valeur pour chaque entité-type qui y participe : exactement un client, exactement une facture, exactement une réservation. Autrement dit, les clients qui n’ont pas réservé sont exclus de l’association, donc on ne peut pas avoir de facture en ce qui les concerne...

Ça c’est pour la théorie, mais je n’ai aucune idée de ce que votre AGL générera comme MLD à partir de votre MCD, car il peut ne pas être conforme à Merise ; en tout cas une chose est sûre :

Selon votre (1er) MCD :

— Une facture fait référence à au moins et au plus un client ;

— Une réservation (si elle existe) fait référence à au plus une facture, donc au client référencé lui-même par la facture.

Alors, si au bout du compte il y a toujours une facture, à laquelle est facultativement associée une réservation, pourquoi ne pas modéliser quelque chose comme ceci (aux attributs près) :




Vous me direz peut-être que la création d’une réservation peut précéder dans le temps la création de la facture : disons que l’entité-type FACTURE intervient dans la gestion de la préfacturation.

ses attributs doivent aussi changer?

Les attributs faisant double emploi doivent disparaître : par exemple, si la date de location est la même dans FACTURE et RESERVATION, alors elle est redondante et doit évidemment disparaître de RESERVATION (la redondance est un ennemi juré et redoutable pour les bases de données) : pourquoi affirmer deux fois, N fois la même chose quand une fois suffit ?

Vous noterez que deux factures ne peuvent pas avoir le même numéro (cf. ci-dessus, l’attribut NumeroFacture). Le mickey <ai> est synonyme d’identifiant alternatif (alternate identifier).

Incidemment, puisque l’entité-type HISTORIQUE est relative aux factures supprimées, elle ne peut être associée à l’entité-type FACTURE, sinon il y a contradiction : elle ne peut que flotter toute seule dans son coin... Pour la petite histoire, il n’y a que dans les exercices qu’on supprime les factures, en situation réelle, dans les entreprises, on ne supprime jamais une facture (tout du moins avant d’avoir atteint une limite légale, définie par l’Administration).


Si vous avez encore des doutes quant à la transformation de la ternaire PAYER du 1er MCD, n’hésitez pas à poser des questions, de fait ça n’est pas a priori un point si évident.

[bangaromaric]

Bonjour fsmrel, pour le cas de l’entité-type HISTORIQUE et FACTURE lorsqu'une la location est terminée, le gestionnaire (type d'utilisateur) doit le retiré du Dashboard avec l'action supprimer en fait c'est juste un déplacement je vais l'appelé déplacer, Aussi cette action va me permet de ne plus avoir besoin des identifiants de chaque entité-type. Donc c'est une action qui va pas supprimer réellement la facture, elle va juste se charger de changer certains attributs des entités qui font partis de la location exemple: statusChauffeur(occupé) deviendra statusChauffeur(libre), de plus il n'y a que l'administrateur qui peux vraiment la supprimée après avoir fait un back-up des facture du mois. Faudrait faire toujours le lien ou pas?


Concernant l’entité-type FACTURE et RESERVATION, j'avoue que se n'était vraiment pas évident mais pour la redondance c'est compris ensuite pour le numéro effectivement entre deux factures est différent grâce à sa structure définie lors de sa création, est ce qu'il est encore nécessaire le <ai>?


Sur mon deuxième MCD quant à la règle de gestion: un client peut conduire lui même ou prendre un chauffeur.
Est ce qu'elle est vérifié ? Si oui comment l'expliqué.

Et je vais aussi ajouté l'entité-type assurance.
Assurance --1,n----( assurer )----1,n-- Véhicule
avec comme attribut ASR_DATE_DEBUT et ASR_DATE_FIN

[fsmrel]

Bonsoir Leromantiqueroma,

Pour le cas de l’entité-type HISTORIQUE et FACTURE lorsqu'une la location est terminée, le gestionnaire (type d'utilisateur) doit le retiré du Dashboard avec l'action supprimer en fait c'est juste un déplacement je vais l'appelé déplacer.

Descendons d’un cran, passons du conceptuel au concret SQL. Du point de vue de la base de données, je suppose que « déplacer » la facture F1 consiste à supprimer dans la table FACTURE le tuple (ligne) qui la concerne et insérer dans la table HISTORIQUE un tuple contenant toute l’information relative à cette facture, c’est cela ? Sinon, si l'on s'en tient aux cardinalités 0,1 / 1,1 portées par les pattes connectant FACTURE et HISTORIQUE (dernier MCD), la table HISTORIQUE devra être dotée d’une clé étrangère {idFacture} faisant référence à la clé primaire {idFacture} de la table FACTURE, et la facture F1 ne pourra pas être supprimée de la table FACTURE (mais alors on voir mal l’intérêt de la table HISTORIQUE, qui n’est qu’une vaste redondance).

Aussi cette action va me permet de ne plus avoir besoin des identifiants de chaque entité-type

On sort ici du cadre fonctionnel, c’est de la cuisine, ce qu’on appelle de l’« optimisation » et ça ne doit pas figurer au stade de la modélisation conceptuelle : c’est après avoir prototypé les performances qu’on peut objectivement décider de procéder ainsi (et, après trente ans de de prototypage des performances, j’a conclu que ce genre d’optimisation coûte cher en développement et en maintenance, pour un gain en performances minime). Il ne faut donc pas mettre la charrue avant les bœufs. Pour le moment, en l’absence de l’entité-type HISTORIQUE on est mesure (au moins au 1er coup d’œil) de pallier par des jointures de FACTURE avec CLIENT, VEHICULE, CHAUFFEUR, etc. En revanche, que vous créiez une vue SQL qui soit la jointure (LEFT OUTER JOIN en ce qui concerne la table CHAUFFEUR) des 4 tables en cause (5 si on prend en compte la table UTILISATEUR), pas de problème, ça ne pourra être que bénéfique pour la simplification des consultations.

Vous me direz : si à la date à laquelle on a édité la facture F1, le client se prénommait Raoul et si depuis il se prénomme Gaston, en l’absence de la table HISTORIQUE, on perd une information. Mais il faut voir aussi qu’il n’est pas interdit d’adjoindre sa table « historique » à chacune des tables CLIENT, VEHICULE, CHAUFFEUR, etc.

statusChauffeur(occupé) deviendra statusChauffeur(libre)

Il s’agit là encore d’une information redondante. En effet, pour savoir si à telle date tel chauffeur est occupé, il suffit d’un requête SQL portant sur la table FACTURE et comparant les dates.

est ce qu'il est encore nécessaire le <ai>?

Bien sûr. La structure d’un numéro de facture est une chose et la manipulation des données en est une autre. On n’est jamais à l’abri d’une erreur de manipulation faisant qu’on retrouve plus d’une fois le même numéro de facture dans la table FACTURE : on ne blinde jamais assez les bases de données, il faut rester dans la logique « ceinture, bretelles et épingle à nourrice ».

Sur mon deuxième MCD quant à la règle de gestion: un client peut conduire lui même ou prendre un chauffeur.
Est ce qu'elle est vérifié ? Si oui comment l'expliquer.

C’est l’association INCLURE entre FACTURE et CHAUFFEUR qui permet de savoir si le client a pris ou non un chauffeur. Partons des tables :

CLIENT {idClient, ...}

CHAUFFEUR {idChauffeur, ...}

FACTURE {idFacture, idClient, ...}

INCLURE {idFacture, idChauffeur}

Si la table FACTURE contient une facture d’identifiant idFacture =314116 faisant référence au client d’identifiant idClient=007, et si la table INCLURE contient aussi l’identifiant idFacture =314116, faisant référence au chauffeur idChauffeur=12345, alors le client 007 a eu recours au service du chauffeur 12345.

Si la table FACTURE contient une facture d’identifiant idFacture =54786 faisant référence au client d’identifiant idClient=3571, et si dans la table INCLURE il n’existe pas de ligne idFacture =54786, alors le client 3571 n’ pas eu recours aux services d’un chauffeur.


La table FACTURE représente vraiment le cœur de votre modèle et doit faire l’objet de la plus grande attention...

[bangaromaric]

Donc si je comprends bien supprimer le lien entre historique et facture et le laissé sans relation avec ses attributs est une solution ?
Supposons que l'entité historique n'existe plus et qu'il y a une facture déjà créée et on voudrait supprimer un chauffeur pour un raison ou une autre sachant que sont ID est inscrit dans une facture comment faire?

[fsmrel]

Bonsoir Leromantiqueroma,

si je comprends bien supprimer le lien entre historique et facture et le laissé sans relation avec ses attributs est une solution ?

Dans la mesure où un tuple de la table HISTORIQUE contient tous les éléments permettant de reconstruire la facture historisée F1, cette facture ne doit plus être présente dans la table FACTURE (et bien entendu le lien entre FACTURE et HISTORIQUE n’a pas à exister) : HISTORIQUE se suffit à elle-même et flotte toute seule dans son coin, sans lien avec quoi que ce soit.

Supposons que l'entité historique n'existe plus et qu'il y a une facture déjà créée et on voudrait supprimer un chauffeur pour un raison ou une autre sachant que sont ID est inscrit dans une facture comment faire?

La base de données doit être cohérente, l’intégrité référentielle doit être garantie par le SGBD. Autrement dit, si la facture F1 fait référence au chauffeur Ch1, la suppression de celui-ci sera impossible (même principe pour les véhicules, les clients ou les utilisateurs). Pour pallier, vous pouvez prévoir un attribut de type booléen dans la table CHAUFFEUR, pour signifier que le chauffeur Ch1 fait actuellement partie de la maison ou non. Vous pouvez aussi définir une date d’embauche et une date de démission. Il y a une alternative, conforme à la théorie de l’historisation dans le cadre de la théorie relationnelle, mais je ne voudrais pas vous embarquer dans une affaire assez compliquée.

Du point de vue théorique, l’historisation est un sujet assez aride, traité en plus de 500 pages dans l’ouvrage de C.J. Date, H. Darwen et N. Lorentzos Time and Relational Theory, Second Edition: Temporal Databases in the Relational Model and SQL. Pour un petit aperçu, vous pouvez jeter un coup d’oeil ici.

[bangaromaric]

Bonsoir Leromantiqueroma,




Dans la mesure où un tuple de la table HISTORIQUE contient tous les éléments permettant de reconstruire la facture historisée F1, cette facture ne doit plus être présente dans la table FACTURE (et bien entendu le lien entre FACTURE et HISTORIQUE n’a pas à exister) : HISTORIQUE se suffit à elle-même et flotte toute seule dans son coin, sans lien avec quoi que ce soit.





La base de données doit être cohérente, l’intégrité référentielle doit être garantie par le SGBD. Autrement dit, si la facture F1 fait référence au chauffeur Ch1, la suppression de celui-ci sera impossible (même principe pour les véhicules, les clients ou les utilisateurs). Pour pallier, vous pouvez prévoir un attribut de type booléen dans la table CHAUFFEUR, pour signifier que le chauffeur Ch1 fait actuellement partie de la maison ou non. Vous pouvez aussi définir une date d’embauche et une date de démission. Il y a une alternative, conforme à la théorie de l’historisation dans le cadre de la théorie relationnelle, mais je ne voudrais pas vous embarquer dans une affaire assez compliquée.

Du point de vue théorique, l’historisation est un sujet assez aride, traité en plus de 500 pages dans l’ouvrage de C.J. Date, H. Darwen et N. Lorentzos Time and Relational Theory, Second Edition: Temporal Databases in the Relational Model and SQL. Pour un petit aperçu, vous pouvez jeter un coup d’oeil ici.

Bonsoir fsmrel, un grand merci pour les éclaircissements, je pense que les règles de gestion atteindront 2 pages , une piste sur ce sujet est la bienvenue au fait que faire lorsqu'un problème a été résolu sur le forum ?

[fsmrel]

Bonsoir bangaromaric,

je pense que les règles de gestion atteindront 2 pages , une piste sur ce sujet est la bienvenue

Il est bon de commencer par présenter le sujet, le domaine que l’on traite (chez les initiés, on parle d’univers du discours, ça fait quand même plus chic), c'est-à-dire le QUOI (règles de gestion des données) et non pas le COMMENT (règles concernant le traitement).

Ainsi, votre univers du discours est consacré à la gestion d’un parc automobile, il y a déjà là une information indispensable, certes vue à 100 km d’altitude, mais qui fixe déjà un cadre pour celui qui vous lit. On descend à 10 km d’altitude, en précisant qu’il s’agit (ce que le lecteur intuite, mais ça va mieux en le disant) de la facturation de véhicules à des clients d’une entreprise (ou d’un ensemble d’entreprises, ce qu’on peut subodorer, mais sans prendre de pari...)

A ce stade, vous pouvez (devez) commencer à mettre en évidence les types d’objets principaux de l’univers :

Les véhicules, les clients, les chauffeurs, les factures ;

Avec certains raffinements, constitués par les réservations. L’historisation n’a pas à être considérée à ce stade, car c’est quelque chose de compliqué, mais de périphérique, qui relève plus du COMMENT et risque d’embrouiller l’approche du cœur de l’application : la facturation elle-même. Chaque chose en son temps.

De façon corollaire, ce qui est secondaire ne doit pas perturber la rédaction (et la lecture !) ça sera traité un peu plus tard, une fois le coeur stabilisé.

Chaque type d’objet doit bien sûr être décrit soigneusement, de sorte qu’on en ait une compréhension dépourvue d’ambiguïté. Si je vous présente un MCD sec, sans présentation préalable, et qu’y figure par exemple une entité-type TITRE avec des attributs du gente idTitre, libelleTitre, dateCreation, statutTitre, vous pourriez vous dire : mais de quoi parle-t-on ? de titres de civilité (« Madame », « Monsieur », « Docteur ») ? de titres d’ouvrages littéraires (« Les trois mousquetaires », « Vingt ans dans un mur, la vie d’une brique ») ? de titres boursiers (« Alstom », « Danone ») ? du titre des boissons alcoolisées (champagne, malt écossais, vodka...) ? Que sais-je ?

Ainsi, vous devez expliquer ce que sont des véhicules dans votre univers : sont-ce des diligences ? des automobiles ? des chars à voile ? Une fois la définition générale donnée, vous pouvez caractériser ces véhicules, en précisant qu’ils sont tous immatriculés, qu’ils sont d’un certain modèle, ont un certain kilométrage, etc. Bref on atterrit.

Même chose pour les autres types d’objets principaux :

Ainsi, vous parlez de la possibilité qu’a un client de faire une réservation ou de directement louer une voiture, de conduire lui même, ou de prendre un chauffeur.

On est déjà dans l’élaboration des règles de gestion des données, tant à l’usage de l’utilisateur (qui n’est pas informaticien mais se doit valider ce qui est raconté dans le dossier), qu’à l’usage du développeur.

Ceci fait, vous pourrez commencer à reproduire ces types d’objets sous forme d’entités-types dans un MCD, avec leurs attributs (tous décrits ! C’est fastidieux, ch..., mais nécessaire si on pense à la maintenance de l’application, sinon, à titre d’exemple, vos successeurs se diront plus tard : mais à quoi correspond donc cet attribut etatVoiture ?)

Vous noterez que lorsque vous écrivez qu’une location fait l'objet d'une facture, je raye la suite de la phrase : « lorsqu'une facture est supprimée elle inscrit toutes ses informations dans l'entité historique ». En effet, on est déjà dans le COMMENT, car après tout la suppression d’une facture peut être « logique » (entité-type FACTURE : ajout d’un attribut de type un booléen signifiant que la facture est ou n’est pas supprimée).

Tout naturellement, on en arrive à une partie le plus souvent délicate mais néanmoins cruciale, à savoir mettre en oeuvre et justifier les règles qui gouvernent les relations entre les types d’objets. Voyez par exemple la relation CONDUIRE de votre 1er MCD : on apprend que tel chauffeur a conduit tel client avec tel véhicule : on apprend certes quelque chose, mais c’est insuffisant, car ce sont les relations avec les factures qui portent véritablement l’information utile.

Quant à la façon de rédiger ces relations, voyez par exemple ce qu’écrit CinePhil dans son blog : « Règle de gestion bien écrite ».

Mais bien sûr, c’est un jeu subtil qui demande de l’entraînement. Ainsi, quand on écrit « un client a à payer au moins une facture et au plus plusieurs », « une facture est payée par au moins et au plus un client », on a déjà l’association PAYER. Mais il ne faut pas tomber dans le piège de la réservation :

Si au lieu d’écrire : « Une facture d’un client peut en plus comporter une réservation », on écrit plutôt : « Au règlement d’une facture peut facultativement s’ajouter le règlement d’une réservation » (le mot « client » a été gommé), alors on en vient à modéliser ceci, comme on l’a déjà vu :





Diagramme selon lequel on sait parfaitement quel client a effectué quelle réservation, sans qu’il soit donc nécessaire de faire participer la réservation au paiement de la facture par le client.

En tout cas, évitez les associations ternaires avec une (ou plusieurs) cardinalité(s) maximale(s) à 1. Ceci influencera dans le bon sens la rédaction de vos règles.

que faire lorsqu'un problème a été résolu sur le forum ?

1) Voter pour les réponses qui ont pu vous aider

2) Cliquer sur « Résolu » (à côté de « Répondre à la discussion ») :

Bonne route, avec ou sans chauffeur !

[bangaromaric]

Bonsoir fsmrel ,

Bonsoir bangaromaric,

Mais bien sûr, c’est un jeu subtil qui demande de l’entraînement. Ainsi, quand on écrit « un client a à payer au moins une facture et au plus plusieurs », « une facture est payée par au moins et au plus un client », on a déjà l’association PAYER. Mais il ne faut pas tomber dans le piège de la réservation :

Si au lieu d’écrire : « Une facture d’un client peut en plus comporter une réservation », on écrit plutôt : « Au règlement d’une facture peut facultativement s’ajouter le règlement d’une réservation » (le mot « client » a été gommé), alors on en vient à modéliser ceci, comme on l’a déjà vu :
Diagramme selon lequel on sait parfaitement quel client a effectué quelle réservation, sans qu’il soit donc nécessaire de faire participer la réservation au paiement de la facture par le client.

La procédure est correcte je vais l'utiliser. Le attribut numéroDeFacture sur mon AGL jMerise je trouve pas la clé <ai> mais c'est pas bien grave vais trouver un moyen de l'insérer.
Lorsque j écris une règle de gestion entre deux entités est ce que je suis obligé de faire un vas et viens ex: "un permis peux être utilisé par plusieurs clients et un client utilise un seul ou plusieurs permis " permis (0,n)-----utiliser-----(1,n) client.
Et pour facture et réservation pourquoi ne pas dire: une réservation donne lieu à une facture (facturation )et une facture peux être donnée par une réservation .
Et l entité-type historique pas besoin de règle de gestion

1) Voter pour les réponses qui ont pu vous aider

2) Cliquer sur « Résolu » (à côté de « Répondre à la discussion ») :

Bien recu.

[fsmrel]

Bonsoir bangaromaric,

sur mon AGL jMerise je trouve pas la clé <ai> mais c'est pas bien grave vais trouver un moyen de l'insérer

Vous pouvez effectivement le faire manuellement au stade du code SQL (clause UNIQUE dans l’instruction CREATE TABLE), le tout est de ne pas oublier de le faire...

Lorsque j écris une règle de gestion entre deux entités est ce que je suis obligé de faire un vas et viens ex: "un permis peux être utilisé par plusieurs clients et un client utilise un seul ou plusieurs permis " permis (0,n)-----utiliser-----(1,n) client.

Oui. Il faut effectivement préciser la règle côté PERMIS et côté CLIENT :

(R1) Un permis peut être utilisé par plusieurs clients ;

(R2) Un client utilise au moins un permis.

Cela dit, par permis vous sous-entendez manifestement catégorie de permis. Pour lever toute ambiguïté , il faudrait renommer l’entité-type PERMIS en CATEGORIE_PERMIS (ou TYPE_PERMIS) , donc reformuler les règles, par exemple :

(R1) Une catégorie de permis peut être utilisée par plusieurs clients ;

(R2) Un client rentre dans au moins une catégorie de permis.

Autre remarque : La patte connectant l’entité-type CLIENT et l’association POSSEDER est porteuse d’une cardinalité 1,N : si un client n’a pas de permis, il ne peut donc pas louer de voiture, même s’il propose de passer par les services d’un chauffeur ?

Et pour facture et réservation pourquoi ne pas dire: une réservation donne lieu à une facture (facturation) et une facture peux être donnée par une réservation.

Vous pouvez bien sûr formuler ces deux règles ainsi. Simplement, il faudra ensuite attirer l’attention du lecteur sur le fait que cette réservation est faite par le client qui règle la facture. En l’occurrence, je fais référence à ce que avez écrit dans votre 1er message :

« Le client à la possibilité de faire une réservation ou de directement louer une voiture »

Là encore, il s’agit de faire attention aux ambiguïtés inhérentes à la rédaction et les MCD doivent permettre de pallier.

Et l entité-type historique pas besoin de règle de gestion

Si elle n’entretient aucune relation avec les autres entités-types, il suffit effectivement d’expliquer son rôle, d’expliquer et justifier ses attributs.

[bangaromaric]

Bonsoir fsmrel,

Bonsoir bangaromaric,

Autre remarque : La patte connectant l’entité-type CLIENT et l’association POSSEDER est porteuse d’une cardinalité 1,N : si un client n’a pas de permis, il ne peut donc pas louer de voiture, même s’il propose de passer par les services d’un chauffeur ?

Effectivement le client peut loué une voiture sans avoir de permis c'est une erreur de frappe.

[fsmrel]

Rebonsoir,

Vu les votes... Est-ce qu'on approche de ce que vous recherchez ? Y a-t-il des points non (ou mal) traités ?

[bangaromaric]

Rebonsoir,

Vu les votes... Est-ce qu'on approche de ce que vous recherchez ? Y a-t-il des points non (ou mal) traités ?

Non il est résolu merci fsmrel