Sur le code:
-> tu ne vérifies pas la valeur de nt et pourtant tu boucles dessus (nt+1) pour faire du dt[a]=0...
Et vu que tu as déclaré "int dt[20]" ça ne doit pas être triste quand tu donnes une valeur de nt à plus de 18...
Evidemment c'est la même chose ensuite quand tu fais les cin sur les "d[i][j]" et ça se retrouve dans l'utilisation de "r" plus tard.
Comme C++ est très gentil, il ne plantera pas, en revanche je te dis pas la tronche des data autour de tes variables en mémoire...

-> ensuite ton code n'est pas franchement un modèle niveau présentation alors même qu'il est simpliste. Pas de tabulation après les "if", des lignes sautées on se demande bien pourquoi (pour aérer le code?), des noms de variables qui ne ressemblent à rien (sonnerie, love ???), des fois on a:
if()
code

des fois
if()
{code;}

des fois:
for()
code

des fois

for
{
code
}

-> des fois des printf, des fois des cout..., -=1 parfois et -- ailleurs

-> et puis bien sûr les goto... Alors, je veux bien que dans un code extrêmement compliqué et pompé sur d'autres languages on puisse faire du goto (et encore...), mais là... il n'y a absolument aucune raison car tu peux très facilement les remplacer par une boucle while (ou autre) et par un "break;".


Bref si tu cites Dieu dans ton code on se demande en effet bien ce qu'il fait dans cette galère...

Pour ce qui est de mon avis (soulant), j'ai repris ce que tu disais " cependant il me semble que mettre des return est aussi fatigant que de lancer des exceptions".
Dans mon sens saoulant = fatigant.

Sinon, y'a une erreur là:
if($exp = filter_var($exp,FILTER_VALIDATE_EMAIL))
dans le meilleur des cas, c'est ==, mais il vaut mieux tester si tu reçois false:
if(filter_var($exp,FILTER_VALIDATE_EMAIL)===false)

Pour ce qui est des exceptions, c'est simple. Une exception doit rester... une exception et non pas une règle, et puis un utilisateur ne pensera peut être pas au fait que tu ais utilisé des exceptions et soit obligé de faire un try / catch sous peine de voir planter son programme.
Imagine qu'il y ait:
prise de commande
validation de la commande
envoi d'un mail
autre traitement
s'il ne pense pas à faire un try / catch et que par malheur ta classe sorte une exception non traitée, la partie qui suit l'envoi du mail ne sera pas faite.

Maintenant, si tu as envie de bosser de cette manière, dans cette philosophie après tout pourquoi pas :) le tout c'est de choisir et de t'y tenir.

Bah si c'est juste pour faire un exemple, ok.
Ceci dit, pour les exceptions, je trouvais juste lourdingue d'obliger l'utilisateur de ta classe à utiliser un try / catch dans le code principal, c'est tout :)

Ceci dit, tu utilises $confirmation dans ta classe, mais il n'est jamais initialisé, il sert à quoi?
A moins que ce soit le résultat du mail?
return  "Your email have been sent";
dans ce cas il faudrait plutôt faire: $this->confirmation="Your email have been sent";

-> Bon, sinon ça sert pas à grand chose de faire le ==TRUE:
        if(($this->verifAdMail($this->exp)&&$this->verifAdMail($this->dest)
            &&$this->verifCont($this->cont)&&$this->verifSubject($this->subject))==TRUE
soit tu ne mets rien (pas de ==TRUE), soit tu mets ===TRUE pour vérifier qu'en plus c'est un booléen, mais bon, très honnêtement vu que c'est ton code, tu peux t'en dispenser.
D'autre part, comme tu mets des throw exception partout au cas où la vérification échoue on se demande même si ça sert à quelque chose de mettre ça dans un if? Autant faire appel aux méthodes directement vu que ta classe va "planter" en cas de problème.
$this->verifAdMail($this->exp);
$this->verifAdMail($this->dest);
$this->verifCont($this->cont);
$this->verifSubject($this->subject);

-> Ensuite, pour ta vérification d'email:
    private function is_email($exp){
        if(!empty($exp)){
        $exp = filter_var($exp,FILTER_VALIDATE_EMAIL);
Ca peut ne pas être correct. En effet filter_var renverra bien un email dans le cas où $exp est un mail correct, mais il peut également renvoyer un booléen false si le check a échoué! Dans ce cas $exp ne sera pas empty mais $exp sera failse mais ta fonction renverra true...
D'autre part, tu changes la valeur de $exp, ce qui pourrait poser soucis par la suite...

Pour les fonctions non compatibles Windows, tu peux déjà voir si elles sont accessibles par des tests sur l'existence des fonctions.

Comme disait mon prof d'informatique: "un bon programmeur est un fainéant, il fait aussi peu de code possible." mais ça n'est pas à prendre non plus au pied de la lettre. Si déjà faire une classe te saoule (return) imagine plus tard dans un vrai soft... Tu ne vas pas pouvoir caser des exceptions de partout sinon imagine la tronche de ton code.

Bah s'il aime tant que ça les exceptions et que c'est une "règle" dans son code, ok.
C'est juste que je sais que je n'utiliserai pas une classe en l'état qui ne fonctionnerait qu'avec ça, ça revient à écraser une fourmi avec un caterpillar.
Il y a évidemment d'autres solutions comme le "message" qu'il appliquait avant qui pourrait contenir le message d'erreur (ou de validation) et les méthodes renvoyer dans ce cas un booléen en cas de succès / échec. Mais bon, après c'est une religion personnelle je suppose ^_^

Quelques remarques aussi de mon côté ^_^
-> Tu utilises des fonctions checkdnsrr qui ne fonctionnent pas sous Windows (cf help PHP),
-> l'utilisation de "mail" est parfois bridée chez les hébergeurs et peut virer au cauchemar dans le cadre d'un serveur perso, donc je rejoins depression, prévois un cas où tu peux utiliser un serveur SMTP avec login / mot de passe,
-> tu encapsules ton code dans un if pour l'envoi du mail:
        if(!empty($this->exp)
        &&!empty($this->dest)
        &&!empty($this->cont)
        &&!empty($this->subject)){
  autant faire un return si une des variables est empty (à la première), le code sera plus lisible, ça fait une indentation pour rien là, d'autant plus qu'au final tu testes les variables deux fois avec le else ensuite.

-> je pense qu'il manque aussi la gestion des erreurs dans tes "set":
    public function setDest($dest){
        if($this->verifAdMail($dest)){
            $this->dest=$dest;
        }
    }
Si le $dest est incorrect, le $this->dest sera donc à "" et dans le meilleur des cas ton utilisateur aura un message "Le champ du destinataire est vide". Or il était pas vide, il était incorrect.
Bref peut être que tes setxxx devraient revoyer true ou false (ou un message d'erreur) selon que la verif a marché ou non. Comme ça tu pourrais dire à l'utilisateur "adresse mail incorrecte" ou un truc dans le genre.

Dans ton code "principal":
-> tu fais un try / catch dans ton code. C'est sympa, mais un peu inutile à mon sens. Si le mail n'a pas été envoyé, renvoie un booléen ou un message texte plutôt par un return classique.
D'autre part, sauf erreur je vois qu'en cas de mail envoyé avec succès tu utilises $this->message... Or cette variable n'est jamais utilisée (dans le code principal ou la classe), ni même définie dans la classe?

Bref un return "mail envoyé avec succès" ou return "erreur lors de l'envoi du mail" me semble suffisant. Lever une exception pour ce style de code me paraît too much, surtout si quelqu'un utilise ta classe ensuite.

Oui pour le md5() c'était juste pour donner une méthode basique de cheminement et de code pour php. Comme ce genre de chose se retrouve très aisément dans les codes / tutos sur internet ça permets déjà de lui donner une idée.

Après bien évidemment ce n'est pas la panacée le md5, loin de là pour les raisons déjà données :)

Ensuite pour la sécurisation totale d'un soft ça peut aller beaucoup plus loin, du log systématique des query / login / accès à l'utilisation de logs générés par mod_security que l'on peut installer pour Apache. Mais bon comme vous l'avez dit, tout est une question de juste milieu tout de même :)

Euh... Je ne pense pas que nous ayons été très agressifs :)
D'autre part, tu dis que tu travailles sur la V2 et sur les points signalés, très bien, il faut comprendre que nous revevons ici car on reçoit des notifications par mail, on ne passe pas sur ton site tous les jours pour voir où tu en es ce sujet sert à ça...

Pour les mots de passe, je pense que tu fais une confusion.
Si l'on te parle de crypter le mot de passe, c'est lors du stockage dans la base de données pour qu'il ne soit pas "en clair" dedans.

Je donne un exemple en md5:
Lors de l'inscription, ton utilisateur choisit comme mot de passe "coucou", tu le récupères dans ton code PHP et tu calcules sa signature en md5 (il suffit d'utiliser la fonction php md5() ) ce qui donne "721a9b52bfceacc503c056e3b9b93cfa" (normalement). L'avantage du md5 c'est que tu peux calculer une signature, mais tu ne peux pas, en partant d'une signature, retrouver le mot de passe originel (sauf en utilisant des dictionnaires ou le brute force, mais c'est une autre histoire).
Donc tu stockes dans ta base de données la signature "721a9b52bfceacc503c056e3b9b93cfa" pour cet utilisateur.

Quand ton utilisateur reviens et se loggue, il entre son mot de passe "coucou", tu calcules la signature du mot de passe qu'il a rentré (coucou) en md5 et tu la compares à la signature md5 qui est dans ta base de données.

En faisant comme ça, tu protèges tes utilisateurs car si la bdd se fait voler ou exploiter (sql injections ou autres) au moins les mots de passe seront cryptés.


Comme tu le vois, il n'y a donc aucune relation entre cryptage, et nombre de caractères dans le mot de passe ici :)

Si l'utilisateur décde de changer de mot de passe, tu peux toujours vérifier que l'ancien est correct avant de le changer pour un nouveau. En revanche, tu ne pourras pas toi le récupérer.
Ce que font la plupart des sites c'est qu'en cas de perte du mot de passe, ils l'écrasent par une chaîne aléatoire et qu'ils envoient le nouveau mot de passe sur le mail donné lors de l'inscription.

Salut :)
Même remarque pour la sécurité, en Mysql il suffit de penser juste au typage et à mysql_real_escape_string (enfin, en gros...), autant le faire dès le départ que de se fader tous ses fichiers (quand on a pas de POO, c'est là qu'on voit que ça sert :) ).

Autre chose, toujours au niveau de la sécurité, apparemment le mot de passe est en "clair" dans la base de données. Déjà tu pourrais le stocker en md5() là aussi en une fonction tu sécurises un peu plus.

Sinon le fait de mettre des "@" devant toutes les commandes mysql juste pour cacher la misère en cas de plantage me paraît pas trèèèès judicieux :)
Autant faire une classe pour ça et traiter l'erreur éventuel (surtout si comme tu le dis c'est un proto et que tu veux savoir où et pourquoi ça plante).

Pour stocker les infos bdd tu crées un fichier php (system/data.php) mais sans vérifier s'il a bien été crée (ou si tu as les droits pour dans le dossier en question) ou pas et ensuite tu l'utilises dans pas mal de fichiers. Là encore pas de tests à l'ouverture en création du fichier.

Autre chose, dans system/modules.php (et aussi ailleurs):
if(empty($name) OR empty($actif))
if ( $actif == 'Oui' AND $name == 'Navigation')
tu devrais voir les opérateurs de comparaison booléens, || pour le OR et && pour le AND.

C'est exactement ce que je cherchais à faire depuis un moment...
Merci beaucoup ;)