Alsacreations.com - Actualités - Archives (mars 2026)
Les dernières actualités d'Alsacreations.com
ICQ, le programme de messagerie instantanée qui a innové et en a inspiré bien d'autres... et qui a été oublié silencieusement.
Plus qu'un rétrospective nostalgique, nous verrons que :
- ICQ a fortement influencé et contribué à établir les messageries d'aujourd'hui
- Sa communauté, son outils et son site sont révélateurs des pratiques, du design, et des contenus que l'on pouvait espérer trouver sur Internet à différents moments chronologiques
1996, une idée géniale
L'histoire commence dans les bureaux d'une société de Tel Aviv nommée Zapa Digital Arts, spécialisée dans les outils graphiques 3D pour Internet. Quatre développeurs s'y rencontrent : Yair Goldfinger, Sefi Vigiser, Amnon Amir et Arik Vardi. En 1996, ils quittent Zapa et décident de se lancer dans quelque chose de nouveau : ils créent ICQ en moins de deux mois (yolo, sans financement).
C'est le père d'Arik, entrepreneur, qui accepte d'investir quelques centaines de milliers de dollars pour donner vie à l'idée. Mirabilis - nom de la société ainsi formée - s'établit dans un petit appartement à San Jose, en Californie, où l'accès à Internet était moins coûteux. Mirabilis, vient du latin et signifie « choses merveilleuses ». Le nom ICQ joue sur une homophonie anglaise : ICQ se prononce « I Seek You », c'est-à-dire « Je te cherche ». Bien plus poétique que Teams qui rime avec bugs.
ICQ pose les bases des clients de messagerie instantanée indépendants dès son lancement en. Windows 95 avait à peine un an, Nintendo venait de sortir la N64, et moins d'une personne sur 100 disposait d'un téléphone mobile... pour téléphoner uniquement.
Avant ICQ, la communication en temps réel sur Internet, c'était surtout IRC (Internet Relay Chat), qui existe toujours, mais réservé aux initiés. ICQ était plus simple et conquit alors plus de dix millions d'utilisateurs avec des fonctionnalités très agréables pour cette époque.
L'idée centrale qui nous semble évidente aujourd'hui était révolutionnaire : savoir qui, parmi ses contacts, était en ligne à un moment donné, et pouvoir lui envoyer un message immédiatement. Pas un e-mail qui attendrait des heures dans une boîte, long à rédiger et peu adapté pour une conversation instantanée.
L'UIN
L'une des particularités d'ICQ est son système d'identiants. Plutôt qu'un pseudonyme choisi par l'utilisateur (comme AIM - AOL Instant Messenger - et d'autres équivalents le feraient plus tard) ou une adresse e-mail (comme MSN Messenger), ICQ utilisait un numéro d'identification unique (UIN) pour chaque utilisateur, attribué dans l'ordre d'inscription. Les premiers inscrits obtenaient donc des numéros courts (5 ou 6 chiffres), véritables graals d'early adopters. Arborer un UIN à 6 chiffres, c'était un peu l'équivalent d'avoir eu un compte Twitter à 3 lettres. Ce numéro... je m'en souviens encore par coeur vingt ans plus tard (j'avais un 8 chiffres), permettait de rechercher d'autres utilisateurs sur la plateforme, ou d'être contacté.
On pouvait être fier d'avoir un compte ICQ et commander un t-shirt avec l'UIN imprimé dessus.
ICQ ne se contentait pas d'envoyer des messages texte. Son arsenal de fonctionnalités était impressionnant et comme c'était la mode en ces temps reculés, il fallait sans cesse ajouter des modules différents dans une interface de plus en plus complexe.
Messagerie asynchrone hors-ligne
Si votre contact était déconnecté, le message lui parvenait dès qu'il se reconnectait. La possibilité de recevoir des messages hors-ligne et de les lire plus tard n'était pas standard avant qu'ICQ ne la rende possible. À l'époque des connexions dial-up où personne ne restait connecté 24h/24, c'était rudement pratique.
On pouvait aussi démarrer une session de discussion par écrit en temps réel, voir les mots saisis et apparaître au fur et à mesure (personnellement lorsque j'ai découvert cette fonction, j'étais autant mindblown que Marty observant la Delorean dépassant les 88 miles/heure.
ICQ avait - par défaut - une philosophie différente d'autres clients de messagerie instantanée qui faisaient surgir une fenêtre à chaque nouveau message reçu. Avec ICQ, on entendait la notification, l'icône clignotait dans la barre des tâches et on pouvait choisir de s'en occuper plus tard : le message pouvait attendre.
Les statuts de présence
Les indicateurs de statut affichant « Disponible », « Absent » ou « Ne pas déranger » sont nés du design pionnier de l'interface ICQ. Oui, cette petite pastille verte ou rouge très simplifiée que vous voyez dans Teams ou Slack vient d'ICQ qui disposait de statuts avec icônes déclinées autour du thème floral.
Transfert de fichiers
Envoyer une photo ou un fichier directement à un contact, sans passer par e-mail ? En peer-to-peer ? ICQ le faisait dès les premières versions, avec en prime la possibilité de reprendre un transfert interrompu. Quand on pense que c'était très compliqué à réaliser en HTTP, FTP et qu'il y avait des programmes spécialisés pour cela (tels que GetRight).
Chat de groupe, répertoire mondial
ICQ proposait plusieurs fonctionnalités de chat multi-utilisateurs, et des annuaires de groupes sur son site. On pouvait chercher des inconnus par nom, email ou centre d'intérêt. ICQ était, d'une certaine façon, le premier réseau social mondial. On pouvait aussi envoyer un message à plusieurs destinataires, d'un seul coup.
ICQPhone
ICQPhone était un service de téléphonie passant des appels vocaux, en utilisant la technologie VoIP (Voice over IP). Audacieux car - si vous en vous en souvenez pas - les télécommunications étaient payantes à la durée et d'autant plus sur de longues distances, tandis qu'Internet permettaitde s'affranchir de cette limite... pour ceux qui avaient une connexion illimitée.
Le son qui a traumatisé toute une génération
Impossible de parler d'ICQ sans évoquer LE fameux son : « Uh Oh ! ».
Il y avait aussi le son de démarrage d'un paquebot arrivant au port pour le démarrage...
Le son de connexion d'un contact ou de déconnexion avec une porte qui s'ouvre et se ferme, ou un toc-toc-toc
.
...toute une panoplie d'effets cultes. ICQ introduisait également la notion de smileys dans les conversations.
1998 : AOL rachète ICQ pour une grosse somme
Le succès viral d'ICQ n'avait pas échappé aux géants de l'époque. Selon les rumeurs Yossi Vardi, assistant à une conférence technologique aux États-Unis, présenta ses chiffres directement à la direction d'AOL. Ces projections, qui se révélèrent exactes, enflammèrent l'imagination des dirigeants d'AOL et les négociations commencèrent. En juin 1998, AOL racheta l'intégralité des actifs de Mirabilis pour 300 à 400 millions de dollars.
Pourtant ICQ ne générait aucun revenu. Pas d'abonnement, pas de publicité, pas de freemium. Le rachat reposait entièrement sur la valeur de la base utilisateurs et du concept. C'était les prémices de la bulle, et cela ressemblait beaucoup à ce que Facebook payerait pour WhatsApp seize ans plus tard. Sous AOL, ICQ continua de croître. America Online réussit à multiplier par dix la base d'utilisateurs d'ICQ au cours des trois années suivantes, dépassant les 100 millions d'utilisateurs inscrits en 2001.
Le site web d'ICQ devenait un véritable portail de contenus et de fonctionnalités, comme c'était la mode, à l'instar de Yahoo.
Un véritable labyrinthe de pages, toutes différentes les unes des autres, avec un design limité par ce que la technique, les langages et les programmes de conception graphique pouvaient laisser faire.
Trop de fonctionnalités, trop de concurrence, trop de spam
ICQ et influencé de nombreux programmes de chat populaires de l'époque, notamment AOL Instant Messenger, Yahoo! Messenger et MSN Messenger. Paradoxalement, ce sont ses propres "descendants" qui l'enterrèrent. AIM bénéficiait de l'écosystème AOL déjà dominant aux États-Unis. MSN Messenger était préinstallé avec Windows. Yahoo Messenger s'appuyait sur le moteur de recherche le plus populaire du monde. ICQ, lui, devait se battre seul.
ICQ est devenu au fil du temps une usine à gaz multipliant les fonctionnalités et augmentant la lourdeur du logiciel. Version après version, l'interface s'alourdit de publicités, de mini-jeux, d'un navigateur intégré, d'une messagerie vocale...
À tel point qu'une version "Lite" (allégée) a vu le jour.
Une version Java baptisée "ICQ2Go" destinée à être embarquée sur des sites et autres systèmes avait aussi été dévoilée.
On a aussi vu apparaître - tendance de l'époque - la barre d'outils pour navigateur (enfin surtout Internet Explorer).
Comme la messagerie instantanée était nouvelle pour beaucoup de gens à la fin des années 1990, les problèmes qui existent encore aujourd'hui étaient déjà présents aux débuts d'ICQ : vol de comptes, phishing et spam. Les UIN courts et faciles à mémoriser étaient des cibles.
Vous ne vous souvenez peut être pas des débuts de Twitter où il était possible de s'en servir également par SMS, mais ICQ pouvait aussi fonctionner (très partiellement) ainsi.
L'arrivée des smartphones signa l'arrêt de mort des messageries desktop de la première génération. WhatsApp, iMessage, puis Telegram redéfinirent la messagerie autour du numéro de téléphone — un identifiant/numéro que tout le monde possédait déjà.
Et pourtant il y eut une tentative d'incursion dans l'univers des applications mobiles avec "ICQ new".
Les services proposés étaient toujours plus vastes : e-cards à envoyer, skins à télécharger, tout ce qui a fait le charme de la première décennie du web grand public.
2010-2024 : l'ère russe
Alors qu'AOL voulait se débarrasser du service, la tâche s'avéra difficile en raison de sa réputation d'héberger de nombreux utilisateurs malveillants et du fait que l'acheteur potentiel était une firme russe, Digital Sky Technologies. Les autorités américaines craignaient que la vente ne complique les enquêtes sur les utilisateurs d'ICQ. Mais la transaction se conclut quand même.
En 2010, AOL vendit ICQ à Digital Sky Technologies, qui deviendra Mail.ru, puis VK, pour 187 millions de dollars — moins de la moitié de ce qu'AOL avait payé douze ans plus tôt. En 2020, VK tenta un sursaut avec « ICQ New », une refonte moderne. En 2022, les applications mobiles furent retirées des stores Google et Apple. Selon sa page Wikipedia, ICQ comptait encore 11 millions d'utilisateurs mensuels en 2022.
Le 24 mai 2024, VK posta un message sobre sur icq.com :
ICQ will stop working from June 26.
Pas de grand billet de blog, pas d'au revoir pour vingt-huit ans d'histoire de liquidés en une phrase. Le 26 juin 2024, ICQ cessa officiellement ses opérations.
Malgré tout, ICQ a survécu à ses principaux concurrents : AIM ferma en 2017, le programme de communication Yahoo disparut en 2018, et Microsoft mit fin à son client Messenger en 2014. Cruel destin : le pionnier survécut à tous ceux qui l'avaient copié, avant de s'éteindre le dernier.
Connaissez-vous encore votre numéro ICQ ? Si comme mes quelques neurones vous avez encore ce souvenir, alors vous faites partie d'une génération qui a connu les messageries avant les réseaux sociaux, avant les smartphones, via un petit programme de 2 Mo, sur les premières connexions grand public. ICQ a posé les fondations sur lesquelles repose chaque message que vous envoyez aujourd'hui.
Le protocole SMTP (Simple Mail Transfer Protocol), défini dans les années 1980 et toujours en vigueur, a été conçu à une époque où l'Internet était un petit club de personnes qui se faisaient confiance. Résultat : n'importe qui peut techniquement envoyer un e-mail en prétendant être contact@votre-banque.fr ou zozodu68@france.gouv.fr. Aucune vérification d'identité n'est prévue nativement dans le protocole.
Immense fail, mais jamais on aurait pu imaginer en 1982 (RFC 821) que l'on s'exposerait ainsi à du spam, du phishing et de toutes les formes d'usurpation d'identité par e-mail.
Pour y remédier, trois mécanismes complémentaires ont été introduits au fil des années, tous basés sur une autre architecture : DNS (Domain Name System) avec les enregistrements SPF, DKIM et DMARC. Ils ne modifient pas SMTP lui-même, mais ajoutent une couche de vérification externe. On part du principe que si vous prouvez détenir un nom de domaine, alors vous devez être garants des solutions d'expédition d'e-mail pour ce domaine.
Si votre domaine n'est pas correctement configuré, vous êtes louche, et vous ne passerez pas.
Autrement dit, les opérations vont en grande majorité se passer du côté de votre registrar ou panel de gestion de votre nom de domaine pour adapter votre zone DNS. Il ne s'agira pas de faire pointer votre nom de domaine vers l'adresse IP de votre hébergeur comme c'est souvent le cas mais d'alimenter par d'autres lignes au format texte qui prouveront que vous n'êtes pas un ignoble spammeur.
â ï¸ Les captures d'écran suivantes sont des exemples imaginaires et ne sont pas des modèles à suivre, chaque configuration est à adapter à votre situation.
Les trois protagonistes
ð¥ SPF (Sender Policy Framework)
SPF permet de déclarer dans la zone DNS quels serveurs sont autorisés à envoyer des e-mails au nom de votre domaine. Le serveur destinataire vérifie si l'IP d'expédition figure dans la liste. Simple et efficace, mais limité : il ne protège que l'adresse technique d'expédition (MAIL FROM), pas le champ From: visible par l'utilisateur.
ð¥ DKIM (DomainKeys Identified Mail)
DKIM appose une signature cryptographique sur chaque e-mail envoyé. Le serveur d'envoi signe le message avec une clé privée ; la clé publique est publiée dans le DNS. Le destinataire peut ainsi vérifier que le message n'a pas été altéré en transit et qu'il provient bien du domaine annoncé. C'est bien mais ça ne suffit toujours pas à empêcher l'usurpation du From: affiché à l'utilisateur.
ð¥ DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC est la pièce maîtresse qui donne du sens aux deux précédents. Il définit une politique : que faire si SPF ou DKIM échouent ? Tolérer ? Mettre en quarantaine ? Rejeter ? DMARC exige aussi une correspondance entre le domaine vérifié par SPF/DKIM et le From: visible ce qui bouche enfin la faille principale. En bonus, il permet de recevoir des rapports sur les tentatives d'usurpation de votre domaine.
Configuration : intérêt, syntaxe et subtilités
SPF : Déclarer ses serveurs d'envoi
SPF se configure via un enregistrement DNS de type TXT sur votre domaine. La syntaxe ressemble à ceci :
v=spf1 ip4:203.0.113.42 include:_spf.google.com include:spf.brevo.com ~all
Syntaxe :
v=spf1: version du protocoleip4:203.0.113.42: autorisation d'une IP spécifiqueinclude:_spf.google.com: délégation à Google Workspaceinclude:sendgrid.net: délégation à Sendgrid~all: résultat softfail pour tout le reste (les messages passent mais sont marqués)-all: hard fail tout le reste est rejeté (recommandé en production)
La difficulté principale est de lister exhaustivement tous vos prestataires d'envoi. Plateforme de newsletters, outils de support, formulaires de contact, notifications... chaque service qui envoie en votre nom doit être référencé. Et le nombre de mécanismes include: est limité à 10 lookups DNS, au-delà la règle est invalide.
DKIM : Signer cryptographiquement ses messages
DKIM nécessite une paire de clés RSA (ou Ed25519). La clé privée est configurée côté serveur d'envoi ; la clé publique est publiée en DNS sous la forme :
selector1._domainkey.votredomaine.fr TXT "v=DKIM1; k=rsa; p=XXXXXXXX..."
Le sélecteur (selector1) permet d'avoir plusieurs clés actives en simultané ou pour des sous-systèmes différents. La difficulté reste que la clé privée doit être configurée dans votre serveur SMTP ou chez chaque prestataire d'envoi. Si vous utilisez cinq outils différents, chacun a sa propre façon de faire et certains ne le proposent pas, ou facturent l'option en supplément.
De plus, les modifications en transit (listes de diffusion qui ajoutent un footer, certains proxies) peuvent casser la signature DKIM. C'est du joli.
DMARC : La politique et les rapports
DMARC se publie lui aussi côté DNS, avec des mots clés techniques bien gratinés :
_dmarc.votredomaine.fr TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.fr; ruf=mailto:forensics@votredomaine.fr; pct=100; adkim=s; aspf=s"
Les paramètres clés :
| Paramètre | Valeur | Signification |
|---|---|---|
p |
none / quarantine / reject |
Politique appliquée en cas d'échec |
rua |
mailto:... |
Adresse pour les rapports agrégés quotidiens |
ruf |
mailto:... |
Adresse pour les rapports forensiques (message par message) |
pct |
0–100 |
Pourcentage de messages soumis à la politique |
adkim |
r (relaxed) / s (strict) |
Alignement requis pour DKIM |
aspf |
r / s |
Alignement requis pour SPF |
La stratégie recommandée est de déployer progressivement : commencer par p=none pour observer sans rien bloquer, analyser les rapports, corriger les problèmes, puis passer à quarantine et enfin reject.
Surprise : les rapports DMARC sont en XML, lisibles par une machine, pas par un humain. Il existe des outils en ligne pour les parser (DMARC Analyzer, Postmark, dmarcian…), mais ça représente un suivi actif. Les rapports ruf (forensiques) posent aussi des questions de confidentialité car ils contiennent des informations sur les messages rejetés ce qui explique que beaucoup de destinataires ne les envoient plus.
<!-- Extrait d'un rapport DMARC agrégé XML -->
<record>
<row>
<source_ip>209.285.320.41</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
Pour tester rapidement si on passe l'étape DMARC sur Gmail, c'est très simple : envoyer un mail à une adresse @gmail, attendre la réception, cliquer sur Afficher l'original dans le menu contextuel du mail, et vérifier que DMARC : 'PASS'.
â ï¸ DMARC s'applique aux sous-domaines via le paramètre sp= (subdomain policy). Si vous envoyez depuis newsletters.votredomaine.fr, cette adresse a ses propres enjeux SPF/DKIM et une mauvaise configuration peut impacter la délivrabilité du domaine principal. Chaque sous-domaine utilisé pour l'envoi mérite sa propre attention.
Microsoft et sa sauce propriétaire
L'élément déclencheur de cet article : Microsoft a décidé, avec raison sur le fond, de renforcer l'application de ces standards mais aussi de changer les méthodes d'authentification SMTP pour les personnes gérant leur solution via Office365 / Outlook / Azure / quel-que-soit-son-nom. Sur la forme, c'est une autre histoire (on dirait que ce sont les mêmes personnes qui ont réfléchi - ou pas - à l'UX de Teams). Il n'est plus possible de s'en servir avec le vénérable protocole SMTP.
La communication autour de ces changements a été éparpillée entre plusieurs blogs techniques, souvent contradictoire selon qu'on parle d'Outlook.com (grand public), d'Exchange Online (Office 365) ou d'Azure Communication Services. Toujours aussi limpide. Les délais annoncés ont changé plusieurs fois. Des administrateurs ont découvert des bugs en constatant que des e-mails critiques n'arrivaient plus, sans message d'erreur clair.
Ce n'est pas que Microsoft ait tort de l'exiger DMARC devrait être obligatoire partout depuis des années. Mais la manière dont le déploiement a été géré illustre parfaitement le paradoxe Microsoft : énoncer des standards de sécurité pertinents, dans un écosystème dont la complexité décourage leur mise en œuvre correcte. Sans compter que les explications restent souvent floues et la gestion d'Azure est un vrai labyrinthe qui nécessite parfois l'intervention de personnes sachant s'en sortir avec la philosophie de Microsoft.
Conclusion : son propre serveur SMTP ou un prestataire ?
Après tout ça, une question légitime se pose : vaut-il mieux gérer soi-même son infrastructure d'envoi ou déléguer à un prestataire spécialisé (Brevo, Postmark, Sendgrid, Mailgun, Amazon SES et équivalents) ?
Gérer son propre serveur SMTP
Avantages : contrôle total, pas de dépendance externe, coût potentiellement réduit pour de gros volumes.
Inconvénients : la configuration SPF/DKIM/DMARC est entièrement à votre charge. Il faut aussi gérer la réputation d'IP (une IP fraîche ou mal configurée sera bloquée par les grands FAI), surveiller les listes noires, gérer les rebonds. C'est un métier à part entière. Les erreurs ont des conséquences immédiates sur la délivrabilité.
Du côté d'Amazon SES vous avez un suivi fin de ces scores dans la console d'administration, et il faut négocier avec eux ou risquer d'être bannis si votre réputation n'est pas à la hauteur.
Passer par un prestataire spécialisé
Avantages : SPF et DKIM sont souvent pré-configurés ou guidés pas à pas. Les prestataires sérieux maintiennent une bonne réputation d'IP, gèrent les rebonds et les désinscriptions, et fournissent des outils d'analyse. La mise en conformité est beaucoup plus rapide.
Inconvénients : coût récurrent, dépendance à un tiers, et il faut quand même comprendre DMARC pour configurer la politique finale sur votre domaine. Les prestataires ne font que la moitié du travail.
La recommandation pragmatique
Pour la grande majorité des projets web, utiliser un prestataire d'envoi transactionnel (Postmark et Brevo sont particulièrement bien documentés sur ces sujets) est le choix le plus sensé. Vous gagnez du temps, vous bénéficiez d'infrastructures éprouvées, et vous pouvez vous concentrer sur DMARC la partie qui vous appartient vraiment. De plus il y a souvent des formules gratuites qui suffisent largement pour un usage courant.
Dans tous les cas, ne pas configurer ces mécanismes n'est plus une option valable. Les grands acteurs (Google, Microsoft, Yahoo) l'exigent désormais explicitement pour les expéditeurs de volume. Et même pour les petits sites, un p=reject correctement configuré protège votre réputation de domaine contre l'usurpation ce qui vaut largement le temps de mise en place.
Et pour WordPress ?
Envoyer des emails depuis WordPress : la solution native
WordPress propose par défaut une fonctionnalité d'envoi d'emails via la fonction wp_mail(), qui utilise la configuration de PHP, elle-même définie par la configuration interne au serveur d'hébergement (parfois pas du tout, parfois le serveur lui-même, parfois un vrai serveur SMTP distinct). Cette solution est simple à configurer : il suffit d'utiliser des extensions comme Contact Form 7 pour envoyer des emails depuis votre site. Cependant, cette méthode présente les mêmes risques identifiés précédemment : les emails peuvent être marqués comme spam, car les serveurs partagés et mal configurés n'ont pas toujours une bonne réputation. Enfin, vous n'avez que très peu de contrôle sur les logs ou les statistiques d'envoi à moins de réellement mettre les mains dans SSH, ce qui rend difficile le dépannage en cas de problème (merci grep et /var/log/mail.log). Cette solution convient pour des sites basiques ou des tests rapides, mais elle est déconseillée pour un usage professionnel. En local avec Docker vous pouvez utiliser msmtp qui est très léger et mailpit.
Optimiser les envois : extensions SMTP ou API dédiées
Pour améliorer la délivrabilité, deux approches s'offrent à vous :
- Via une extension SMTP (comme WP Mail SMTP ou FluentSMTP) : ces extensions permettent de configurer un serveur SMTP externe en renseignant vos identifiants. L'avantage ? Une meilleure authentification, avec de vrais enregistrements SPF, DKIM, DMARC si vous les avez bien configurés pour un vrai serveur SMTP, et un suivi des erreurs. Cependant, cette méthode nécessite de gérer manuellement les identifiants.
- Via une API spécialisée (comme Brevo, SendGrid, Postmark ou Azure) : ces services offrent une infrastructure dédiée, des tableaux de bord avancés (statistiques, rebonds, plaintes pour spam) et une intégration fluide, voire simplifiée : l'envoi se fait via des clés API, ce qui élimine le besoin de stocker des mots de passe. Idéal pour les sites à fort trafic ou les campagnes marketing, cette solution garantit une délivrabilité optimale et une gestion professionnelle des emails.
Ressources utiles
- MXToolbox SPF/DKIM/DMARC checker pour tester la configuration
- Mail Tester : score de délivrabilité
- DKIM Validator
- Learn DMARC visualiser le fonctionnement de SPF, DKIM, et DMARC
- RFC 7208 SPF
- RFC 6376 DKIM
- RFC 7489 DMARC
Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com