Je cherche un FAI qui me permette d'envoyer des pièces jointes de + de 10 Mo. Lesquels proposent les offres les + intéressantes ?  

il va être content ton destinataire!
 
je te dirais qu'à ce niveau, autant faire ton serveur SMTP.

www.infomaniak.ch... pour environ 90 euro/an tu n'as plus aucune limite, tant en réception qu'en envois.
 
Totuefois il faut que tu saches que l'email n'est pas la meilleure méthode poru envoyer des fichiers. l'encodage en base64 fait gonfler de 33% les fichiers pendant leur transmission par rapport au FTP ou HTTP.

 
Et qu'est-ce que l'encodage en base 64 ?

Et quelle est la limite imposée par Wanadoo ? Je l'ai cherché sur leur site, mais je n'ai pas trouvé cette info...  

et pourkoi pas faire tes transferts de fichier par FTP ?
et puis kes ke tuveux lui envoyer ?

 
base64 est un encodage qui permet d'utiliser seulement 64 caractères, et de passer sans problème les système de messagerie les plus archaïque sur 7 bits.
 
Par exemple voici un fichier reçu par email, il est encodé en base64 :
 

 
Voici en gros comment ca fonctionne :
 
1) tu prends 24 bits (3 octets)
2) tu lis 6 bits (reste 18 bits) comme une valeur entière
3) tu fais correspondre un caractère ASCII à cette valeur
4) tu lis les 6 bits suivants (reste 12 bits)
5) tu fais correspondre un caractère ASCII à cette valeur
6) tu lis les 6 bits suivants (reste 6 bits)
7) tu fais correspondre un caractère ASCII à cette valeur
8) tu lis les 6 bits suivants
9) tu fais correspondre un caractère ASCII à cette valeur
 
Tu regroupe les résultats de point 3, 5, 7 et 9 ce qui te donne 4 octets ou 32 bits. Ton fichier a gonflé de 33% en passant par email... ce qui n'est pas le cas avec HTTP ou FTP qui sont des protocoels qui permettent de transférer directement des données binaires.
 
Pour avoir 64 caractères il te faut 6 bits (2^6 = 64, lis le ^ comme "puissance" )
 
Les valeurs en fonction des 6 bits que tu lis de la table de remplacement des caractères sont les suivantes :
 

 
Prenons un exemple, j'ai un fichier de 3 octets qui contient ces données : 00110000'11011000'10001010
 
Je lis les 6 premiers bits (tu peux utiliser la caculatrice de Windows pour convertir) :
001100 = 12 = M
 
Puis les 6 suivants :
001101 = 13 = N
 
Les 6 suivants :
100010 = 34 = i
 
Les 6 derniers :
001010 = 10 = K
 
Le fichier ci-dessus encodé en base64 est donc : MNiK
 
Evidemment quand tu reçois un fichier par email tu appliques la méthodes inverses pour le décoder.

pour ces explications détaillées, mais je ne comprends pas pourquoi la taille augmente de 33%...
 
Si l'on passe de 00110001101100010001010 à MNiK, n'y aurait-il pas plutôt une compression d'espace ?  

autant prendre un compte sur yahoo ^^

 
Note : les espaces ou apostrophes sont juste la pour rendre le tout plus lisible.
 
Non ! La raison c'est que un 0 ou 1 représente un bit... et un caractère alphabétique représente en général 1 octet (= 8 bits), donc 4 caractères représentent 32 bits (4 * 8).
 
La chaîne de caractères "MNiK" représentée en binaire avec une table ASCII 8 bits s'écrit :
 
01001101'01001110'01101001'01001011 (32 bits)
 
Ce qui est équivalent à la chaîne suivante encodée en base64 :
 
00110000'11011000'10001010 (24 bits)
 
Après pourquoi la chaîne de caractères "MNiK" t'a parue plus comptacte, c'est juste une question de représentation... par exemple en hexadécimal (en base 16) la même chaîne serait représentée de la manière suivante : 4D 4E 69 4B
 
(Voir une table de caractères ASCII, tu contstateras que 4D = M, 4E = N, 69 = i et 4B = K)
 
Mais je pourrais au la représenter en décimal (base 10) : 77 78 105 75
 
Pour résumer :

 
En clair pour transférer 24 bits de données binaires (ou 3 octets) par email il te faut 32 octets (ou 4 octets) sur un système 8 bits (= la totalité des ordinateurs actuels)... par conséquent transférer des fichiers lourds par emails n'est pas une bonne idée.

AOL autorise 15 Mo, mais c'est vraiment abuser ce genre de pj..