Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Quelle syntaxe pour une adresse de courriel ?

26 réponses
Avatar
Olivier Miakinen
[ publication dans fr.comp.lang.php et fr.comp.mail,
suivi dans fr.comp.mail seul ]

Bonjour,

Lassé de voir tant de fonctions de contrôle des adresses de courriel
incorrectes, qui refusent par exemple les adresses « plussées » comme
la mienne (om+news en partie gauche) mais aussi les TLD¹ de plus de
trois caractères tels que .name, .aero ou .museum, j'ai l'intention de
faire inclure dans la FAQ de fr.comp.lang.php une fonction correspondant
mieux à la réalité.

Du coup, j'ai lu les RFC 952 et 1035 (noms de domaine), 2822 (format de
messages), 3696, et d'autres.

Il en ressort les choses suivantes.

1) Pour la partie gauche, avant l'arrobe (@)
--------------------------------------------
1a) Cette partie est composée d'une ou plusieurs sous-parties séparées
par des points (.).
1b) Chaque sous-partie est constituée d'au moins un caractère (donc on
n'a pas de point au début, ni à la fin, et on ne peut pas non plus
avoir deux points de suite.
1c) Les caractères suivants peuvent être utilisés tels quels, sans
protection :
- les lettres majuscules et minuscules sans accent (A à Z et a à z)
- les chiffres (0 à 9)
- les caractères !#$%&'*+-/=?^_`{|}
1d) Cela étant, on peut toujours utiliser d'autres caractères, y
compris l'espace ( ) et l'arrobe (@) à condition de les protéger,
par exemple <"John@Doe"@example.com> ou <John\ Doe@example.com>.

2) Pour la partie droite, après l'arrobe (@)
--------------------------------------------
2a) Cette partie est aussi composée d'une ou plusieurs sous-parties
séparées par des points (.).
2b) Là encore chaque sous-partie est constituée d'au moins un caractère.
2c) D'après le RFC 952, la syntaxe de chaque sous-partie est très
stricte :
- d'abord une lettre (A à Z ou a à z)
- suivie éventuellement par un certain nombre de lettres, de
chiffres (0 à 9) et de traits d'union (-)
- mais ne pouvant finir que par une lettre ou un chiffre (donc
pas un trait d'union
2d) D'après le RFC 1035, la syntaxe décrite ci-dessus n'est qu'une
« preferred syntax », tandis qu'en réalité à peu près n'importe
quelle chaîne de bits pourrait être stockée dans un DNS.
2e) L'expérience montre que les noms de sous-domaine ne commencent
pas forcément par une lettre, et d'ailleurs ne contiennent même pas
obligatoirement de lettre (ex : 123.net ou 93.fr).
2f) En revanche, il semble établi que le trait d'union ne peut jamais
être le premier ni le dernier caractère d'un nom de sous-domaine.
2g) Le RFC 1035 limite chaque nom de sous-domaine à 63 octets au
maximum, et le FQDN² à 255 octets au maximum.
2h) Le RFC 3696 considère qu'en dehors des applications chargées de
gérer les TLD eux-mêmes, tout nom de domaine devrait être un FQDN
avec donc au moins un point (.) séparant deux sous-domaines.

3) Pour l'ensemble
------------------
Le RFC 3696 limite la partie gauche à 64 octets au maximum, soit un
total de 320 octets au maximum pour l'adresse complète (64+1+255).


Tout ceci étant posé, j'envisage de conserver les règles suivantes :
(1a), (1b) et (1c) ; (2a), (2b), (2f), (2g) et (2h) ; (3). J'éliminerais
la possibilité (1d). Quant à (2c), (2d) et (2e), j'utiliserais une règle
(2c) assouplie pour accepter un chiffre comme premier caractère de
chaque sous-domaine (ce qui légitime les adresses constatées en (2e)).


En PHP, je construirais donc les expressions rationnelles suivantes :
// partie gauche
$atext = '[A-Za-z0-9!#$%&\'*+/=?^_`{|}-]';
$atom = "$atext+"
$leftpart = "$atom(\.$atom)*";
// partie droite
$letdig = '[A-Za-z0-9]';
$letdighyp = '[A-Za-z0-9-]';
$subdomain = "$letdig($letdighyp{0,61}$letdig)?";
$domain = "$subdomain(\.$subdomain)+";
// expression globale
$regexp = "$leftpart@$domain";

Il ne resterait plus qu'à tester indépendamment les longueurs max
respectives des parties gauche et droite (64 à gauche, 255 à droite).


En espérant ne pas vous avoir assommés avec ce long article, j'espère
avoir vos réactions.

Cordialement,
--
Olivier Miakinen
¹ TLD = Top level domain = domaine de premier niveau
² FQDN = Fully-qualified domaine name = nom de domaine complet

10 réponses

1 2 3
Avatar
BanRay
Des exemples concrêts svp?



"Olivier Miakinen" <om+ a écrit dans le message de news:
dtlle2$1bi8$
[ publication dans fr.comp.lang.php et fr.comp.mail,
suivi dans fr.comp.mail seul ]

Bonjour,

Lassé de voir tant de fonctions de contrôle des adresses de courriel
incorrectes, qui refusent par exemple les adresses « plussées » comme
la mienne (om+news en partie gauche) mais aussi les TLD¹ de plus de
trois caractères tels que .name, .aero ou .museum, j'ai l'intention de
faire inclure dans la FAQ de fr.comp.lang.php une fonction correspondant
mieux à la réalité.

Du coup, j'ai lu les RFC 952 et 1035 (noms de domaine), 2822 (format de
messages), 3696, et d'autres.

Il en ressort les choses suivantes.

1) Pour la partie gauche, avant l'arrobe (@)
--------------------------------------------
1a) Cette partie est composée d'une ou plusieurs sous-parties séparées
par des points (.).
1b) Chaque sous-partie est constituée d'au moins un caractère (donc on
n'a pas de point au début, ni à la fin, et on ne peut pas non plus
avoir deux points de suite.
1c) Les caractères suivants peuvent être utilisés tels quels, sans
protection :
- les lettres majuscules et minuscules sans accent (A à Z et a à z)
- les chiffres (0 à 9)
- les caractères !#$%&'*+-/=?^_`{|}
1d) Cela étant, on peut toujours utiliser d'autres caractères, y
compris l'espace ( ) et l'arrobe (@) à condition de les protéger,
par exemple <""@example.com> ou <John .

2) Pour la partie droite, après l'arrobe (@)
--------------------------------------------
2a) Cette partie est aussi composée d'une ou plusieurs sous-parties
séparées par des points (.).
2b) Là encore chaque sous-partie est constituée d'au moins un caractère.
2c) D'après le RFC 952, la syntaxe de chaque sous-partie est très
stricte :
- d'abord une lettre (A à Z ou a à z)
- suivie éventuellement par un certain nombre de lettres, de
chiffres (0 à 9) et de traits d'union (-)
- mais ne pouvant finir que par une lettre ou un chiffre (donc
pas un trait d'union
2d) D'après le RFC 1035, la syntaxe décrite ci-dessus n'est qu'une
« preferred syntax », tandis qu'en réalité à peu près n'importe
quelle chaîne de bits pourrait être stockée dans un DNS.
2e) L'expérience montre que les noms de sous-domaine ne commencent
pas forcément par une lettre, et d'ailleurs ne contiennent même pas
obligatoirement de lettre (ex : 123.net ou 93.fr).
2f) En revanche, il semble établi que le trait d'union ne peut jamais
être le premier ni le dernier caractère d'un nom de sous-domaine.
2g) Le RFC 1035 limite chaque nom de sous-domaine à 63 octets au
maximum, et le FQDN² à 255 octets au maximum.
2h) Le RFC 3696 considère qu'en dehors des applications chargées de
gérer les TLD eux-mêmes, tout nom de domaine devrait être un FQDN
avec donc au moins un point (.) séparant deux sous-domaines.

3) Pour l'ensemble
------------------
Le RFC 3696 limite la partie gauche à 64 octets au maximum, soit un
total de 320 octets au maximum pour l'adresse complète (64+1+255).


Tout ceci étant posé, j'envisage de conserver les règles suivantes :
(1a), (1b) et (1c) ; (2a), (2b), (2f), (2g) et (2h) ; (3). J'éliminerais
la possibilité (1d). Quant à (2c), (2d) et (2e), j'utiliserais une règle
(2c) assouplie pour accepter un chiffre comme premier caractère de
chaque sous-domaine (ce qui légitime les adresses constatées en (2e)).


En PHP, je construirais donc les expressions rationnelles suivantes :
// partie gauche
$atext = '[A-Za-z0-9!#$%&'*+/=?^_`{|}-]';
$atom = "$atext+"
$leftpart = "$atom(.$atom)*";
// partie droite
$letdig = '[A-Za-z0-9]';
$letdighyp = '[A-Za-z0-9-]';
$subdomain = "$letdig($letdighyp{0,61}$letdig)?";
$domain = "$subdomain(.$subdomain)+";
// expression globale
$regexp = "$leftpart@$domain";

Il ne resterait plus qu'à tester indépendamment les longueurs max
respectives des parties gauche et droite (64 à gauche, 255 à droite).


En espérant ne pas vous avoir assommés avec ce long article, j'espère
avoir vos réactions.

Cordialement,
--
Olivier Miakinen
¹ TLD = Top level domain = domaine de premier niveau
² FQDN = Fully-qualified domaine name = nom de domaine complet


Avatar
mdnews

Des exemples concrêts svp?



- Citation de 97 lignes pour n'en ajouter qu'une seule
- top-postage

+2

Avatar
Olivier Miakinen

Des exemples concrêts svp?


Eh bien par exemple « .aero » et « .museum ». Mais aussi « .info ».

Ce n'était pas ta question ? Mais comment pourrais-je savoir de quoi tu
veux des exemples concrets puisque tu ne réponds à rien de particulier
et que tu cites l'intégralité de mon très long article après ?

Note au passage que des exemples concrets de toutes les paties, il y en
a dans les RFC que j'ai cités.

"Olivier Miakinen" <om+ a écrit dans le message de news:
[ plusieurs dizaines de lignes citées, signature comprise ]


À lire avant les RFC : <http://www.giromini.org/usenet-fr/repondre&gt;.

--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Avatar
Sébastien
En PHP, je construirais donc les expressions rationnelles suivantes :
// partie gauche
$atext = '[A-Za-z0-9!#$%&'*+/=?^_`{|}-]';
$atom = "$atext+"
$leftpart = "$atom(.$atom)*";
// partie droite
$letdig = '[A-Za-z0-9]';
$letdighyp = '[A-Za-z0-9-]';
$subdomain = "$letdig($letdighyp{0,61}$letdig)?";
$domain = "$subdomain(.$subdomain)+";
// expression globale
$regexp = "$leftpart@$domain";

Il ne resterait plus qu'à tester indépendamment les longueurs max
respectives des parties gauche et droite (64 à gauche, 255 à droite).

En espérant ne pas vous avoir assommés avec ce long article, j'espère
avoir vos réactions.


Bonjour Olivier,

Il m'arrive d'utiliser des expressions rationnelles mais je n'en ai
jamais construit de bien compliquées.
Bref, je n'arrive pas à savoir si tes expressions sont du type ereg() ou
preg_match().

J'ai aussi une ressource à soumettre au groupe, qui prétend répondre à
tous les points de RFC 822 et RFC 2822.
http://code.iamcal.com/php/rfc822/

Je ne suis pas spécialiste, ni des expressions rationnelles, ni de la
syntaxe des adresses email, mais j'ai fais quelques tests sur ces
fonctions et elles font ce qu'elles annoncent (dans les tableaux de
résultats).

J'aimerais vraiment avoir une fonction simple et *sûre* pour valider les
adresses e-mail...

Sébastien

P.S : j'ai testé avec la fonction de
http://code.iamcal.com/php/rfc822/rfc2822.phps et pas avec la
mega-expression "tout en un".

Avatar
Olivier Miakinen
Bonjour Sébastien,


Il m'arrive d'utiliser des expressions rationnelles mais je n'en ai
jamais construit de bien compliquées.


Moi non plus : tout dépend bien sûr de ce que l'on appelle compliqué,
mais je n'aimerais pas utiliser une expression rationnelle trop
difficile à lire (telle que celles gérant la syntaxe complète avec
guillemets).

Bref, je n'arrive pas à savoir si tes expressions sont du type ereg() ou
preg_match().


J'envisage de les utiliser avec preg_match(), mais si je ne m'abuse
elles sont assez simples pour être utilisées avec ereg() aussi, puisque
je n'utilise pas d'assertions ou d'autres choses compliquées.

Dans ma proposition actuelle, j'utilise les syntaxes suivantes :
- les crochets pour des classes de caractères ;
- les parenthèses pour rassembler deux choses
- les multiplicateurs « ? », « * », « + » et « {n,p} »
Seule la toute dernière pourrait éventuellement ne pas marcher avec
ereg() mais cela m'étonnerait.

C'est peut-être l'utilisation des variables PHP qui obscurcissait
l'expression pour ceux qui ne sont pas habitués ?
Voici ce que donne l'expression sans variable PHP (mais il faut
supprimer les sauts de ligne) :

[A-Za-z0-9!#$%&'*+/=?^_`{|}-]+
(.[A-Za-z0-9!#$%&'*+/=?^_`{|}-]+)*
@
[A-Za-z0-9]([A-Za-z0-9-]{0,61}[A-Za-z0-9])?
(.[A-Za-z0-9]([A-Za-z0-9-]{0,61}[A-Za-z0-9])?)+

J'ai aussi une ressource à soumettre au groupe, qui prétend répondre à
tous les points de RFC 822 et RFC 2822.
http://code.iamcal.com/php/rfc822/


Je n'ai pas encore regardé en détail, je ferai une autre réponse après
(mais d'autres que moi peuvent aussi réagir).

J'aimerais vraiment avoir une fonction simple et *sûre* pour valider les
adresses e-mail...


La question que je posais au groupe, c'était dans quelle mesure on doit
sacrifier la complétude à la simplicité. Par exemple, dois-je accepter
une adresse du style "John.Doe"@miakinen.net ou "John Doe"@miakinen.net,
ou bien dois-je me limiter seulement à ?

Cordialement,
--
Olivier Miakinen

Avatar
Patrick Mevzek
J'ai aussi une ressource à soumettre au groupe, qui prétend répondre à
tous les points de RFC 822 et RFC 2822.
http://code.iamcal.com/php/rfc822/


Je n'ai pas encore regardé en détail, je ferai une autre réponse après
(mais d'autres que moi peuvent aussi réagir).


Ca semble mettre en oeuvre la même regex que celle que j'ai donné dans
un lien précédemment [1]. A savoir la RFC822 complète, modulo les
commentaires.

[1] je ne me suis pas amusé à vérifier les caractères un par un.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/&gt; <http://www.dotandco.com/&gt;
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>


Avatar
F. Senault

J'aimerais vraiment avoir une fonction simple et *sûre* pour valider les
adresses e-mail...


La question que je posais au groupe, c'était dans quelle mesure on doit
sacrifier la complétude à la simplicité. Par exemple, dois-je accepter
une adresse du style "John.Doe"@miakinen.net ou "John Doe"@miakinen.net,
ou bien dois-je me limiter seulement à ?


Dans la pratique, sur bientôt 10 ans d'administration d'un serveur de
courrier, je n'ai jamais vu d'adresse "exotique"@truc.bidule valide (pas
plus que d'utilisations des caractères de la classe [#{}%&^`{|}]).

Par contre, pour compléter ton expression rationnelle, je te
conseillerais bien de te fendre d'un ([a-z]{2,6}) pour le (cc)TLD (de
mémoire, il me semble que ça suffit).

(J'utilise '[a-zA-Z0-9._+-]+@([a-zA-Z0-9_+-]+.)+[a-zA-Z]{2,6}' ou
quelque chose de très proche, généralement ; c'est simpliste, je sais.)

Fred
--
And if you're taking your girlfriend out tonight You better park the
car well out of sight 'cause if they catch you in the back seat
Trying to pick her locks They?re gonna send you back to mother In a
cardboard box /You better run !/ (Pink Floyd, Run Like Hell)


Avatar
Olivier Miakinen
Bonjour Fred,


La question que je posais au groupe, c'était dans quelle mesure on doit
sacrifier la complétude à la simplicité. Par exemple, dois-je accepter
une adresse du style "John.Doe"@miakinen.net ou "John Doe"@miakinen.net,
ou bien dois-je me limiter seulement à ?


Dans la pratique, sur bientôt 10 ans d'administration d'un serveur de
courrier, je n'ai jamais vu d'adresse "exotique"@truc.bidule valide (pas
plus que d'utilisations des caractères de la classe [#{}%&^`{|}]).


Je te remercie de cette info. Pourrais-tu juste préciser dans quelles
circonstances il t'a été proposé ces caractères exotiques dans des
adresses qui se sont ensuite révélées fausses ? Je te pose la question
puisque la suite de ton article laisse à penser que tu utilises à un
endroit au moins une expression rationnelle assez stricte, expression
qui devrait justement te cacher toutes ces adresses bizarres...

Juste pour savoir aussi : la traduction d'adresses de type Lotus Notes
ou Lotus Domino (X500 ?) ne pourrait-elle pas contenir des « % » par
exemple ?

Par contre, pour compléter ton expression rationnelle, je te
conseillerais bien de te fendre d'un ([a-z]{2,6}) pour le (cc)TLD (de
mémoire, il me semble que ça suffit).


Là je suis un peu réticent. On trouve encore de nombreuses expressions
qui refusent les TLD dont la longueur n'est pas 2 ou 3, et celles-là
risquent d'être encore longtemps sur les sites web et dans les archives.
De la même manière, si je restreins les TLD possibles à {2,6} caractères
il est très possible qu'un .Z ou un .DOMAINS soit créé dès le lendemain.

(J'utilise '[a-zA-Z0-9._+-]+@([a-zA-Z0-9_+-]+.)+[a-zA-Z]{2,6}' ou
quelque chose de très proche, généralement ; c'est simpliste, je sais.)


Je serais plus d'accord avec la restriction aux quelques caractères que
tu listes ci-dessus. Cela dit, interdire d'avoir deux points à la suite,
ou limiter les noms de sous-domaines à 63 caractères, me semble une
restriction plus défendable que de limiter le TLD à 6 caractères.

Tiens, en regardant mieux, je vois que tu interdis déjà les deux points
à la suite dans la partie droite de l'adresse. C'est vrai que dans la
partie gauche c'est peut-être moins embêtant...

Du coup, l'expression pourrait ressembler à ceci :
'[a-zA-Z0-9._+-]+@[a-zA-Z0-9-]{1,63}(.[a-zA-Z0-9-]{1,63})+'


Avatar
F. Senault

Bonjour Fred,


La question que je posais au groupe, c'était dans quelle mesure on doit
sacrifier la complétude à la simplicité. Par exemple, dois-je accepter
une adresse du style "John.Doe"@miakinen.net ou "John Doe"@miakinen.net,
ou bien dois-je me limiter seulement à ?


Dans la pratique, sur bientôt 10 ans d'administration d'un serveur de
courrier, je n'ai jamais vu d'adresse "exotique"@truc.bidule valide (pas
plus que d'utilisations des caractères de la classe [#{}%&^`{|}]).


Je te remercie de cette info. Pourrais-tu juste préciser dans quelles
circonstances il t'a été proposé ces caractères exotiques dans des
adresses qui se sont ensuite révélées fausses ? Je te pose la question
puisque la suite de ton article laisse à penser que tu utilises à un
endroit au moins une expression rationnelle assez stricte, expression
qui devrait justement te cacher toutes ces adresses bizarres...


Non, en fait, j'utilise ce genre d'expressions pour parser des pages web
(notamment mon projet de webnews qui est soigneusement rangé au fond
d'un carton). Au niveau de mes mails, je n'ai pour ainsi dire pas
d'adresse qui ne valide pas l'expression ci-dessous, mais c'est
probablement du au fait que le serveur de courrier valide au minimum
l'adresse de l'enveloppe en testant les MX de la partie domaine (ou A,
enfin, tout ce qui est conforme aux RFCs pour vérifier si l'émetteur
accepte du courrier).

Juste pour savoir aussi : la traduction d'adresses de type Lotus Notes
ou Lotus Domino (X500 ?) ne pourrait-elle pas contenir des « % » par
exemple ?


Probablement, j'ai peut être été un peu large sur ce coup-là.

Par contre, pour compléter ton expression rationnelle, je te
conseillerais bien de te fendre d'un ([a-z]{2,6}) pour le (cc)TLD (de
mémoire, il me semble que ça suffit).


Là je suis un peu réticent. On trouve encore de nombreuses expressions
qui refusent les TLD dont la longueur n'est pas 2 ou 3, et celles-là
risquent d'être encore longtemps sur les sites web et dans les archives.
De la même manière, si je restreins les TLD possibles à {2,6} caractères
il est très possible qu'un .Z ou un .DOMAINS soit créé dès le lendemain.


Et soit utilisé légitimement quelque part entre six mois et quatre ans
après sa création. De quand date la création de .name / .info ? Quand
as-tu reçu pour la première fois un mail légitime venant de ces TLDs ?
Tu as déjà reçu quelque chose de valable en .museum ? Ca laisse
amplement le temps de mettre à jour une expression régulière !

(J'utilise '[a-zA-Z0-9._+-]+@([a-zA-Z0-9_+-]+.)+[a-zA-Z]{2,6}' ou
quelque chose de très proche, généralement ; c'est simpliste, je sais.)


Je serais plus d'accord avec la restriction aux quelques caractères que
tu listes ci-dessus. Cela dit, interdire d'avoir deux points à la suite,
ou limiter les noms de sous-domaines à 63 caractères, me semble une
restriction plus défendable que de limiter le TLD à 6 caractères.

Tiens, en regardant mieux, je vois que tu interdis déjà les deux points
à la suite dans la partie droite de l'adresse. C'est vrai que dans la
partie gauche c'est peut-être moins embêtant...


Je ne sais pas du tout s'il est valide d'avoir .. dans la partie
gauche ; de nouveau, c'expérience, c'est un cas que je n'ai jamais vu se
présenter.

Du coup, l'expression pourrait ressembler à ceci :
'[a-zA-Z0-9._+-]+@[a-zA-Z0-9-]{1,63}(.[a-zA-Z0-9-]{1,63})+'


Tout à fait. Tu peux de toutes manières présenter plusieurs versions de
l'expression - une simpliste (celle-ci), une autre plus stricte (que tu
proposais en début de fil)...

Mais je reste convaincu que le test sur la composition du TLD est a
garder. Au moins, rajoute une clause pour interdire le ".invalid"...
(Sept lettres !) :)

Fred
--
Je regarde le bleu profond se voiler
Parfois, un point lumineux se charge de me rappeler
Que je ne suis pas ici pour paresser
Et que quelque part on a besoin de moi pour aider (Merzhin, Par delà)



Avatar
Sébastien
Bonjour Sébastien,


Il m'arrive d'utiliser des expressions rationnelles mais je n'en ai
jamais construit de bien compliquées.


Moi non plus : tout dépend bien sûr de ce que l'on appelle compliqué,
mais je n'aimerais pas utiliser une expression rationnelle trop
difficile à lire (telle que celles gérant la syntaxe complète avec
guillemets).


Disons que j'en suis au niveau des exemples les plus simples du manuel PHP.

J'aimerais vraiment avoir une fonction simple et *sûre* pour valider les
adresses e-mail...


La question que je posais au groupe, c'était dans quelle mesure on doit
sacrifier la complétude à la simplicité. Par exemple, dois-je accepter
une adresse du style "John.Doe"@miakinen.net ou "John Doe"@miakinen.net,
ou bien dois-je me limiter seulement à ?


Je commence à penser qu'une expression plus stricte (qui accepte moins
de cas légaux mais accepte ce que "les internautes moyens" considèrent
comme valide) peut être une solution acceptable, à condition de ne pas
rejetter les autres, mais plutôt de les faire passer par la fonction
plus complète et de demander une validation manuelle.

Donc :

=> acceptée immédiatement
John => rejetée immédiatement, puis par l'expression
plus complète.

"John.Doe"@miakinen.net => repéchée par l'expression plus complète, mais
en attente de validation.

Mais si cela peut être important et pratique pour une newsletter, ça
risque de compliquer inutilement un simple formulaire de contact...

Ce système permet de ne pas rejetter systématiquement des adresses
légales, tout en permettant de les filtrer au cas par cas, sans avoir à
définir de critères précis (au delà du premier niveau de validation).

Ce n'est qu'une idée pour l'instant, je n'ai pas une énorme expérience
dans le domaine, donc toutes les réactions sont les bienvenues.

Sébastien


1 2 3