Discussion :

[Kropernic]

Bonjour Krop,

Merci chef, j'ai bien compris maintenant
Il me reste une question concernant ces deux tables FOR et CON, c'était quoi l'association entre elles avant de passer au MLD ? (Je suis désolé mais je n'ai pas bien compris cette notation de workbench) est-ce un à un (association fantôme) ?

Ah bin maintenant que vous posez la question, je me rends compte que les cardinalités sont fausses également là aussi... (voilà ce qui arrive quand on fait ça vite pendant son quart d'heure de pause au bureai)
Au niveau MCD, il s'agit en fait d'une association réflexive. J'aurais pu nommer la table TJ_FOR_FOR_JFF mais je trouvais plus parlant de la nommée conversion vu que c'est son usage.
Mais ne prenez pas mon diagramme au pied de la lettre, même si certaines parties sont en l'état car il s'agit de chose avec lesquelles je commence à être coutumier, ce diagramme est plus une piste pour réaliser le vôtre. De ce fait, mes tables FOR et CON ne sont là que pour vous indiquez une manière de faire. A vous de l'adaptez à vos besoins ! (je pense d'ailleurs qu'il manque au moins une colonne à la table FOR pour être pleinement fonctionnelle dans votre cas)

Pour la partie gauche de votre diagramme en bas, y'a toujours une question sans réponse .. Pour mon MCD, j'ai crée une association appelé UTILISER liant les trois entités: ENGIN, ARTICLE, DATE DE SORTIE. En passant au MLD, je ne suis pas tombé sur ce que vous avez trouvé ! Est-ce une erreur de ma part ou bien c'est la même chose sauf la présentation des tables se diffère d'un logiciel à un autre ?

Je n'ai pas vérifier les messages de fsmrel mais n'a-t-il pas abordé ce sujet ? (je me souviens qu'il parle d'une ternaire et il n'y en a que 2 dans votre mcd, j'ai donc une chance sur deux ^^).
Quoi qu'il en soit, pourquoi avoir créer une entité pour date de sortie ? La date de sortie n'est-elle pas la date d'utilisation ? Je placerais donc plutôt la date de sortie en tant qu'attribut de l'association utiliser.
Pour ma part, je considère que la forme de sortie d'un article est la même celle indiquée dans la table ART. Mais encore une fois, c'est à vous de voir. Mis à part certaines situations triviales, je pense qu'il doit y avoir plusieurs modélisations correctes pour représenter conceptuellement un même sujet.

[RZinaoui]

Je n'ai pas vérifier les messages de fsmrel mais n'a-t-il pas abordé ce sujet ? (je me souviens qu'il parle d'une ternaire et il n'y en a que 2 dans votre mcd, j'ai donc une chance sur deux ^^).

On en a parlé mais c'était un autre cas différent de celui là

Quoi qu'il en soit, pourquoi avoir créer une entité pour date de sortie ? La date de sortie n'est-elle pas la date d'utilisation ? Je placerais donc plutôt la date de sortie en tant qu'attribut de l'association utiliser.

Je n'ai fait qu'appliquer une règle de normalisation disant:

• Pour une valeur donnée de l'identifiant de l'association, chaque attribut de cette association doit avoir une et une seule valeur

Vous avez dit :

Bien sûr qu'il (peut) existe(r) plusieurs date de sorties. Qu'est-ce qui interdit un conducteur d'engin de casser plusieurs fois la même pièce de sa machine ?

Donc la règle de la dépendance fonctionnelle n'est pas vérifiée ce qui fait on doit créer une nouvelle entité nommée DATE DE SORTIE. Qu'en pensez vous ?

[fsmrel]

Bonsoir,

Question: comment vous en avez déduit qu'un fournisseur a pu livrer des articles qui ne correspondent pas à la demande ! Normalement le service d'achats et les fournisseurs doivent OBLIGATOIREMENT obéir à ce qu'a demandé le responsable du magasin !! sinon plusieurs engins resteront en panne et la production s'arrêtera !

Considérons votre schéma :




Les demandes d’achat sont transmises au service Achats qui s’occupe des commandes auprès des fournisseurs, so far so good.
En revanche, les livraisons ne sont manifestement pas interceptées par ce service et arrivent directement au magasin de maintenance, ce que confirme par ailleurs votre MCD (association FOURNISSEUR - LIVRAISON). Maintenant, on est en droit de supposer que Gaston qui est magasinier chez le fournisseur Volfoni peu parfois être distrait et mettre dans un colis des ballerines au lieu des tongs commandées...

Quand j’ai effectué mon service militaire, un jour le régiment a reçu des boots d’hiver deux jours avant notre départ pour une manœuvre d’un mois dans la montagne : manque de chance, au lieu de mille paires il y avait deux-mille pieds droits... On a manœuvré avec nos rangers d’été (et il faisait -20°...)

Bien plus tard, alors que je faisais partie d’une SSII et que mon métier c’était la modélisation et les bases de données, mon patron m’avait envoyé en mission chez un de nos clients : l’« article » c’était donc ... moi, manque de chance, il se trouvait que la demande portait sur un ingénieur spécialiste d’UNIX, système dont je ne savais strictement rien, sinon qu’il fallait 10 doigts à chaque main. Bien entendu je revenu aussi sec à la maison mère et mon patron m’a entendu râler, pendant que mes collègues rigolaient...


J’ai plein de choses en cours de rédaction, mais pour ce soir j’en resterai là. A bientôt.

[Kropernic]

Je n'ai fait qu'appliquer une règle de normalisation disant:

• Pour une valeur donnée de l'identifiant de l'association, chaque attribut de cette association doit avoir une et une seule valeur

Vous avez dit :


Donc la règle de la dépendance fonctionnelle n'est pas vérifiée ce qui fait on doit créer une nouvelle entité nommée DATE DE SORTIE. Qu'en pensez vous ?

Bon, on va reprendre calmement ^^.

On savoir qui a utilisé quoi et quand.

Dans mon diagramme, J'ai choisi de modéliser l'utilisation. Au niveau MCD, on a donc l'entité-type UTILISATION (qui devient la table UTI dans mon MLD) ayant pour attribut un identifiant cher à Tabourier et la date de l'utilisation. Voilà pour le quand.

Règle de gestion :
Une UTILISATION utilise plusieurs ARTICLEs et un ARTICLE peut être utiliser par plusieurs UTILISATIONs.

Attention, article n'est pas à prendre au sens "1 litre d'huile" mais dans le sens plus général "de l'huile". Pour savoir combien d'huile, on va placer l'attribut quantité dans l'association. Voilà pour le quoi.
De cette régle, on a donc l'association UTILISER. Le MCD donne ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UTILISATION--1,N--UTILISER--1,N--ARTICLE

Ce qui donnera donc la table JAU dans mon MLD. Attention (je l'ai déjà fait remarquer mais je tape sur le clou) ! J'avais apparemment la tête dans le cul lorsque j'ai réalisé ce MLD et certaines cardinalités sur le diagramme sont fausses et c'est le cas de celles qui nous occupent !!! (de plus, mysqlworkbench met les cardinalités à 1 par défaut, à vous de rectifier celles qui doivent être à 0) La relation entre JAU - ART devrait bien sûr porter la cadinalité N - 1. Et il en va de même pour la relation entre JAU - UTI.

Reste donc à savoir qui !

Cela donne l'entité-type ENGIN ayant pour attribut, de nouveau un identifiant technique, et son identifiant sémantique (que l'utilisateur connait).

Règle de gestion :
Un ENGIN peut effectuer plusieurs UTILISATIONs et une UTILISATION est effectuée par un ENGIN.

Ce qui donne le MCD suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ENGIN--0,N--EFFECTUER--1,1--UTILISATION

Ce qui lors du passage au MLD provoquera la duplication de l'identifiant technique de la table ENG dans la table UTI comme clef étrangère afin de savoir qui a fait l'utilisation.

Et nous avons notre qui !

J'espère avoir été plus clair et je m'excuse encore des erreurs qui se sont glissées dans le MLD... Voici une version "corrigée" (j'espère n'avoir rien oublié).

Je persiste néanmoins à penser que FOR et CON sont incomplètes en l'état. Il faudrait faire une analyse plus détaillée des différentes formes des articles et des conversions à opérer entre elles mais l'idée de base est là.

[RZinaoui]

Maintenant, on est en droit de supposer que Gaston qui est magasinier chez le fournisseur Volfoni peu parfois être distrait et mettre dans un colis des ballerines au lieu des tongs commandées...

au lieu de mille paires il y avait deux-mille pieds droits... On a manœuvré avec nos rangers d’été (et il faisait -20°...)
Bien plus tard, alors que je faisais partie ... pendant que mes collègues rigolaient...

et si je vous dis que le problème pourrait venir du service d'achat ?

C'est ce qui nous est arrivé ce matin, le responsable du magasin avait demandé un liquide de frein E5 flacon 1/2 mais on a reçu un liquide de frein dot 4. Certes, les deux liquides répondent au besoin de réparation du frein mais d'après le magasinier, le seul à avoir un contact avec les engins, on peut utiliser le premier liquide (E5 flacon 1/2) pour réparer également l'embrayage . Si le problème vient du fournisseur, Le magasin n'accepte pas de stocker les articles non conforme à ce qui est demandé et il remplit un bon de retour et l'envoie cette fois-ci directement aux fournisseurs sans passer par le service d'achat.

Le service d'achat n'a pas de contact avec les engins mais ce qui compte pour lui c'est en général de commander des articles avec un prix réduit ce qui peut causer pas mal de problèmes. Reste aussi à signaler les problèmes venant des fournisseurs comme l'exemple que vous nous avez raconté.

J’ai plein de choses en cours de rédaction, mais pour ce soir j’en resterai là. A bientôt.

Je vous attend avec impatience. Bonne journée

[RZinaoui]

Bonjour Krop
Je crois qu'on est bien d'accord maintenant, votre explication était bien claire

Permettez moi de commenter ce que vous avez fait ...
Pour votre MCD, en allant de ENGIN à ARTICLE vous êtes passés par l' intermédiaire de l'entité UTILISATION :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UTILISATION--1,N--UTILISER--1,N--ARTICLE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ENGIN--0,N--EFFECTUER--1,1--UTILISATION

avec l'association utiliser dont la règle de gestion est:

Règle de gestion :
Une UTILISATION utilise plusieurs ARTICLEs et un ARTICLE peut être utiliser par plusieurs UTILISATIONs.

Ici la date d'utilisation qui se présente comme attribut de l'association utiliser ne va pas nous créer un problème de DF car pour un {utilisation_id, article_id} donné il y'a une seule date d'utilisation

et l'association effectuer ayant pour règle de gestion:

Règle de gestion :
Un ENGIN peut effectuer plusieurs UTILISATIONs et une UTILISATION est effectuée par un ENGIN.

C'est bon !

Pour mon MCD, j'ai relié directement les entités ENGIN et ARTICLE sans avoir à passer par l'entité UTILISATION. D'après vous, est-ce ma conception est fausse ou bien les deux démarches sont équivalentes ?

[/U][/B]J'espère avoir été plus clair et je m'excuse encore des erreurs qui se sont glissées dans le MLD

L'être humain est fautif par nature ! Je dois vous remercier pour vos efforts remarquables que vous avez fait pour m'aider. UN GRAND MERCI

Je persiste néanmoins à penser que FOR et CON sont incomplètes en l'état. Il faudrait faire une analyse plus détaillée des différentes formes des articles et des conversions à opérer entre elles mais l'idée de base est là.

Oui, je compte réserver quelques heures pour cette partie, elle est très importante pour la gestion de stock. Merci de m'avoir rappelé ça

[Kropernic]

Pour mon MCD, j'ai relié directement les entités ENGIN et ARTICLE sans avoir à passer par l'entité UTILISATION. D'après vous, est-ce ma conception est fausse ou bien les deux démarches sont équivalentes ?

Quelles sont vos règles de gestion concernant cette partie ?

[RZinaoui]

Un engin peut utiliser plusieurs articles et un article peut être utilisé par plusieurs engins

[Kropernic]

Dans ce cas, pas de table utilisation. Juste juste une table résultant d'une association plusieurs à plusieurs dans laquelle on retrouve les attributs de ma table utilisation.

Mais je trouve qu'on perd alors une information dans le sens qu'on sait pas si les articles demandés par le conducteur de l'engin font partie d'une seule utilisation ou de plusieurs.

[RZinaoui]

Mais je trouve qu'on perd alors une information dans le sens qu'on sait pas si les articles demandés par le conducteur de l'engin font partie d'une seule utilisation ou de plusieurs.

Si, on peut le savoir si on tient compte de la date_sortie dont je vous ai parlé dans les messages précédents. Donc si on prend un engin E qui a utilisé un article A et un article B dans des dates différentes, on peut en déduire le nombre d'utilisation des articles (A et B) demandés par le conducteurs de l'engin.
Qu'en pensez vous ?

[Kropernic]

C'est tendancieux je trouve.

Pour le moment, ça peut passer car on n'aura qu'un seul utilisateur à un instant T.

Mais si dans le futur cela évolue, quid de deux utilisations différentes pour le même engin insérée au même moment ? Bon faut y aller hein... Mais ce n'est pas impossible...

Perso, je préfère ma solution qui est plus robuste. Et qui donne surtout directement l'information "combien d'utilisation pour l'engin E" plutôt que de devoir compter en fonction d'une date.

[RZinaoui]

Effectivement Mr Krop, j'ai fait un exemple pour simuler le cas dont vous avez parlé et j'ai trouvé la fuite si on prend en considération le futur .. Vous aviez raison

J'avoue que j'ai appris autant de choses en essayant de réaliser ce MCD grâce au soutien que vous m'avez apporté vous et fsmrel. Cela développe plusieurs capacités chez la personne ... Merci beaucoup ^^

En attendant l'intervention de Mr fsmrel comme l'a dit:

J’ai plein de choses en cours de rédaction, mais pour ce soir j’en resterai là. A bientôt.

Mr Krop, si vous êtes encore disponible et n'êtes pas fatigué et je crois que ce n'est pas le cas pour ce dernier point , on peut si vous voulez commencer à penser à la requête qui va nous permettre de savoir la quantité actuelle en stock d'un article donné lorsqu'on veut faire un inventaire quotidien, hebdomadaire, mensuel ou annuel !

[Kropernic]

Justement à ce sujet, j'aimerais connaître l'opinion de fsmrel concernant la proposition que j'avais faite d'ajouter une colonne dans la table ART contenant le stock actuel de l'article et qui serait mise à jour au moyen de déclencheur (triggers) à chaque insertion/update des tables adéquates (en l'occurence, je pense ARL et JAU).

De cette manière, plus besoin de requête fastidieuse.

D'autant plus que, au début de la vide la DB, avec quelques lignes dans chaque table, la requête sera performante. Mais avec le temps et les millions de lignes s'accumulant, je crains pour les performances car une telle requête devra en fait parcourir tout l'historique de l'article voulu pour pouvoir déterminer son stock actuel.

Je suis bien conscient qu'il s'agit de là de dénormalisation et qu'il faudrait établir des prototypes pour les tester et constater de manière empirique lequel est le plus performant mais pour la situation, j'ai l'impression que le simple bon sens permet de se rendre compte que l'ajout de cette colonne serait bénéfique. Mais je suis totalement débutant dans ce domaine. C'est pourquoi j'aimerais son opinion.

[RZinaoui]

Bonjour Krop

Hier vous avez dit:

d'ajouter une colonne dans la table ART contenant le stock actuel de l'article et qui serait mise à jour au moyen de déclencheur (triggers) à chaque insertion/update des tables adéquates (en l'occurence, je pense ARL et JAU).

C'est quoi un déclencheur (triggers) ?
Excusez moi ce manque de bagage car ma spécialité (génie industriel et logistique) ne m'a pas permis de rendre plus profond mes connaissances en bases de données.

Question:Est-ce que vous pouvez me l'expliquer brièvement juste pour avoir une idée de quoi vous parlez ?

De cette manière, plus besoin de requête fastidieuse.

Question:Vous voulez dire par ça que ce déclencheur va nous permettre de déterminer automatiquement le stock actuel à partir des sorties, entrées et le stock initial ?

Je suis bien conscient qu'il s'agit de là de dénormalisation et qu'il faudrait établir des prototypes pour les tester

Question:Pourquoi s'agit-il d'une dénormalisation ? et ça concerne quoi au juste ? est-ce que ça va influencer notre MCD ?

[Kropernic]

C'est quoi un déclencheur (triggers) ?

Un déclencheur (trigger est le terme en anglais et celui que j'utilise couramment mais je m'efforce de parler en Français sur le forum autant que possible) est un mécanisme de base de données qui se produit pour une action déterminée.

Par exemple, on pourrait avoir envie pour chaque ligne d'une table de savoir qui a insérée cette ligne et quand. On ajouterait donc les colonnes suivantes à la table T_EXAMPLE_EXA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
EXA_CREATED_BY VARCHAR(100)  NULL,
EXA_CREATED_ON DATETIME NULL

N.B. : Normalement pour ce cas-ci, il vaut mieux utiliser des valeurs par défaut interdire les valeurs marqueurs NULL mais c'est pour l'exemple hein!!
N.B. 2 : Mes exemples de codes sont pour SQL SERVER qui est le seul SGDBR dont je maîtrise plus ou moins la syntaxe et je ne connais pas la syntaxe définie par la norme mais ce doit être ressemblant.

Maintenant, pour mettre de l'information dans ces colonnes, on pourrait le spécifier au programmeur pour qu'il n'oublie pas qu'à chaque insertion d'une ligne dans cette table, il doit spécifier le nom de l'utilisateur et la date d'insertion. Mais ce serait du travail en plus pour lui pour une chose qui ne le concerne pas vraiment (je pars du principe que ce ne sont pas des informations fonctionnelles mais plutôt des informations d'audit).

C'est alors que le DBA peut mettre en place un déclencheur AFTER INSERT sur cette table. Voici ce que cela donnerait :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TRIGGER TR_AFTER_INSERT_EXA ON T_EXAMPLE_EXA
    AFTER INSERT
AS
BEGIN
    UPDATE T_EXAMPLE_EXA
    SET EXA_CREATED_BY = SYSTEM_USER,
          EXA_CREATED_ON = GETDATE()
    WHERE
        EXA_ID IN (SELECT EXA_ID FROM inserted)
END

où EXA_ID est l'identifiant technique de la table.
Ce code se déclenchera donc à chaque nouvelle insertion de ligne(s) dans la table et mettra à jour les colonnes indiquée en prenant le nom de l'utilisateur utilisé lors de la connexion à la DB et la date et heure actuelle du système pour les lignes dont les identifiants correspondent aux identifiants des lignes insérées.

Vous voulez dire par ça que ce déclencheur va nous permettre de déterminer automatiquement le stock actuel à partir des sorties, entrées et le stock initial ?

En ajoutant la colonne ART_STOCK_COURANT à la table ART et en plaçant un trigger AFTER INSERT sur les tables ARL et JAU, nous pourrons automatiquement incrémenté ou décrémenté la valeur de ART_STOCK_COURANT. Alors, une simple requête de sélection tout à fait triviale nous renseignera sur l'état du stock d'un article.

Pourquoi s'agit-il d'une dénormalisation ? et ça concerne quoi au juste ? est-ce que ça va influencer notre MCD ?

Il s'agit de dénormalisation car l'ajout de cette colonne à l'encontre de la Xe forme normale (j'avoue qu'à partir de la 2e, je m'enbrouille dans la forme normale mais vu que je sais que ma manière de structurer mon MCD telle que je l'ai apprise avec fsmrel sur ce forum me garantit une normalisation maximum correcte (restons prudent^^), je n'ai jamais pris la peine de les retenir ). S'il l'application des formes normales est la normalisation, ne plus les respecter est donc de la dénormalisation.
Cela affecte forcément notre MCD puisque nous ajoutons un attribut stock courant dans l'entité article.

En théorie, cet attribut est parfaitement inutile puisque le stock courant peut-être retrouvé par une requête.

----------------------------------------
En écrivant ceci, je me rends compte qu'il doit également être possible d'arriver au même résultat sans toucher à notre entité article mais en utilisant un artifice des SGDBR appelé la vue. Une vue une espèce de table virtuelle basée sur une requête de sélection.

Exemple :
Soit la table client T_CLIENT_CLI dont les colonnes sont :

• CLI_ID INT
• CLI_PRENOM VARCHAR(30)
• CLI_NOM VARCHAR(30)
• CLI_DATE_NAISSANCE DATE

Si nous voulons connaître l'age de nos client, il faut alors compter le nombre d'année d'écart entre la valeur de la colonne CLI_DATE_NAISSANCE et la date du jour. Mais en créant la vue ci-dessous, on peut alors faire une simple requête de sélection sur cette vue pour connaître directement l'âge de nos client. La vue se chargeant de faire les calculs.

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE VIEW V_CLIENT_VCL
AS
SELECT
    CLI_ID,
    CLI_PRENOM,
    CLI_NOM,
    CLI_DATE_NAISSANCE,
    DATEDIFF(MONTH,CLI_DATE_NAISSANCE,GETDATE())/12 AS 'VCL_AGE'
FROM
    T_CLIENT_CLI

Il est donc possible de définir une vue sur la table article qui contiendrait le calcul du stock courant de sorte à ne pas devoir réécrire nous même ce calcul à chaque requête.

Mais je doute néanmoins que ce mécanisme résolve les problèmes de performances que je redoute avec la montée en charge de la DB.
Néanmoins, mon expérience en tant que DBA est encore faible. C'est pour cela que je reste prudent sur ce point et voudrait l'avis d'un expert.

[RZinaoui]

Pour les TRIGGERS, cool maintenant , il faut un petit peu de pratique ..
D'après votre explication, je pense que ça peut marcher .

En ce qui concerne THE VIEW (Celle était l'idée à laquelle j'ai pensé au début et j'en ai sûrement parlé dans certains messages ):
Parmi les règles de normalisation d'un MCD pour la méthode de MERISE, je cite celle-là:

• Toute propriété calculable ne doit pas figurer dans un MCD.

Voilà la dénormalisation dont vous m'avez parlé
Stock_actuel est calculable !
L'exemple que vous avez donné parle à 100% de cette règle car si on connait la date de naissance d'une personne on peut calculer son âge ==> Propriété calculable.
Pour nôtre cas j'ai déjà posé cette question:

(...) parmi les objectifs de cette application c'est d'éviter la rupture de stock en se basant sur l'information portée par stock_actuel. Ma question c'est : est ce qu'on pourrait récupérer cette informations à partir de: stock initial, quantité_ entrée, quantité_sortie, date_entrée, date_sortie ?

Donc si on peut le faire, ça serait magnifique

J'ai essayé de tracer des tables pour trouver une requête convenable mais comme vous l'avez dit il y'a un risque de performance lorsqu'il s'agit des millions d'enregistrements ..

[Kropernic]

Pour bien faire, il faudrait produire la DB normalisée, "lui bourrer la gueule" de données de tests (il existe des outils qui font cela mais je n'ai pas de nom car jamais utilisés) pour ensuite écrire les requêtes de calcul du stock courant et voir les temps de réponses.

Ajouter l'un ou l'autre index si possible et retester.

Si les temps de réponses sont acceptables, on ne fait rien !

Si les temps de réponses ne sont pas acceptables, alors on dénormalise et on recommence les tests.

[RZinaoui]

vous êtes un programmeur, vous me conseillez de travailler avec quoi ? sachant que je peux travailler avec ACCESS et sql server ..

une fois je conclus cette partie de modélisation je vais immédiatement aborder la partie technique qui consiste à concevoir une application pour la gestion de stock. j'aurai besoin de connecter ma base de donné au langage de programmation utilisé tout en essayant de faire une interface homme-machine {ajouter (article, fournisseur, engin...), supprimer, rechercher, demander un article }. J'aimerais bien avoir votre opinion à ce propos.

[Kropernic]

Pour ma curiosité, quel langage allez vous utiliser ?

Car de toute façon, entre access ou sql server, la question ne se pose pas. Je choisis le 2e sans hésitation !

[RZinaoui]

A vrai dire, je ne sais pas encore
On m'a proposé C# en utilisant Visual Studio. Si j'opte pour ce dernier, je devrais regarder du tutoriels et se contenter d'appliquer (imiter) car je n'ai jamais étudié ce langage. D'autres m'ont conseillé de travailler avec JAVA qu'on a vu cette année. Personnellement j'ai travaillé avec Netbeans mais cette programmation est un peu difficile pour moi donc il faut regarder également des tutoriels et appliquer ..
Je cherche à concevoir une application Desktop.
Il me reste moins de deux semaines pour livrer ce produit