29 avril 2011, une date qui restera dans les mémoires ! Un événement unique a rassemblé 2 milliards de personnes. Le rapport avec Magento, vous ne voyez pas ?

Allez, je vous aide. Si les mariages de célébrités ne sont pas votre grande passion et si vous avez une activité e-commerce à faire tourner, vous vous intéresserez peut-être à l’autre événement du jour : la sortie de mon livre sur Magento !

Je pense que j’aurais du mal à en vendre 2 milliards d’exemplaires . Mais s’il peut apporter des réponses concrètes à quelques centaines de commerçants, décideurs, développeurs, web designers et j’en passe, j’en serais très heureux !

J’ai ouvert une rubrique spéciale pour découvrir l’ouvrage et prolonger votre lecture.

Bonne lecture !

Pour l’anecdote, je n’ai toujours pas vu le livre fini, alors que d’autres l’ont commandé, reçu et le lisent déjà ! Les clients sont livrés en priorité, ça c’est du service efficace ! J’espère juste que j’en aurai un…
C’est bon, j’ai enfin la version papier ! Je peux le feuilleter, un vrai petit plaisir.

Dans un mois, mon livre sera dans les bacs. Maintenant que son contenu est figé (il est en cours d’impression), c’est le moment de découvrir son approche et son contenu.

Quelques chiffres

• Environ 570 pages
• Environ 150 000 mots
• 484 figures
• 700 heures de travail (en plus de mon travail quotidien chez Xi Ingénierie)
• 230 e-mails échangés

Comme l’aurait dit Mark Twain, « il ne savait pas que c’était impossible alors il l’a fait ». Maintenant, je le sais, on ne m’y reprendra plus ! Un travail de fou, difficile à évaluer au début car assez éloigné de mes tâches habituelles.

L’approche

Ceux qui utilisent Magento depuis 3 ans le savent bien : ce qui a manqué au début, c’est une documentation sur les concepts importants de Magento, un ouvrage capable de donner une vision globale, tout en se focalisant sur les points-clés.

Alors, j’ai souhaité combler ce manque. Même si tous les détails n’y sont pas (il faudrait des milliers de pages), je voulais que ce livre serve de base de travail pour monter son projet e-commerce et le faire vivre au quotidien.

L’approche est donc résolument pratique et orientée métier. Il est inutile de dérouler les fonctionnalités dans l’ordre d’affichage. Par contre, il est bien plus important de savoir dans quelles circonstances les exploiter.

J’insiste aussi beaucoup sur les bonnes pratiques car, sur le terrain, leur carence se révèle fatale ! Magento est une solution géniale qui impose d’être carré. Mais au final, on en fait ce qu’on veut, tout en isolant les risques.

Le contenu

Comme le plus important est de maîtriser les concepts-clés de Magento, le contenu se découpe en quatre parties très progressives :

• Partie I – Découvrir Magento, enjeux et perspectives
  • 1. Qu’est-ce que Magento ?
  • 2. Offrir le meilleur à ses clients
• Partie II – Gérer un site avec Magento, le quotidien du e-commerçant
  • 3. Notions fondamentales et terminologie
  • 4. Maîtriser le backend
  • 5. Gérer le catalogue
  • 6. Gérer les promotions
  • 7. Gérer le contenu
  • 8. Traiter les commandes
  • 9. Entretenir une bonne relation client
• Partie III – Réaliser un site avec Magento, de la feuille blanche aux premières ventes
  • 10. Préparer son projet
  • 11. Concevoir le catalogue idéal
  • 12. Héberger Magento
  • 13. Installer et mettre à jour Magento
  • 14. Configurer Magento
  • 15. Créer le frontend de ses rêves
  • 16. Optimiser le référencement et la recherche
  • 17. Traduire les contenus
• Partie IV – Dépasser le standard, Magento puissance 10
  • 18. Optimiser les performances de Magento
  • 19. Développer de nouvelles fonctionnalités

Le livre se termine par un index.

Quelles versions ?

Quand j’ai commencé ce projet, Magento Community Edition 1.4.0.0 venait tout juste de sortir. Quand j’ai fini les dernières lignes, nous en étions à la version 1.5.0.1. Le livre couvre donc les séries 1.4 et 1.5.

Je présente aussi Magento Professional Edition, Magento Enterprise Edition, Magento Mobile et Magento Go, sans entrer dans les détails. Je ne suis pas encore prêt à faire l’encyclopédie Magento en 36 volumes ! Par contre, la stratégie de développement de Magento Inc. est un facteur à prendre en compte dans le choix de la solution e-commerce.

Et maintenant ?

Eh bien, il faut encore patienter… Le livre est en pré-commande sur plusieurs sites (Amazon, Fnac, Le Furet du Nord) et sera dans toutes les librairies dans un mois.

Après, ce sera à vous de me dire ce que vous en pensez

Par contre, la comparaison 1.3.2.4 / 1.4.0.0 n’a pu être ajoutée, en raison d’un nombre trop important de modifications dans le code source entre les deux versions. Cela aurait rendu le comparateur illisible, donc inexploitable.

Parmi les petits trucs qu’il vaut mieux ne pas oublier sur un serveur à fort trafic, il y a la purge des sessions Magento. Si vous choisissez de stocker les sessions utilisateurs dans des fichiers (l’autre option étant de les stocker dans la base de données), ils viendront s’ajouter les uns après les autres dans le dossier var/session de Magento, sans jamais être supprimés.

Le problème, c’est qu’un serveur, même puissant et bien optimisé, accepte mal plusieurs millions de fichiers dans un seul dossier. Il devient même impossible de faire une simple commande ls pour lister son contenu : le serveur vous rendra la main plusieurs heures après… s’il y parvient !

Il faut donc purger les fichiers de sessions régulièrement. Les plus pressés feront un simple rm -rf du dossier session. C’est basique mais un peu brutal. Les utilisateurs et clients connectés ne vont pas forcément apprécier la perte de leur session et des commandes en cours…

J’ai eu le cas aujourd’hui sur un serveur dont la purge n’avait pas été mise en place. Avant de l’ajouter, j’ai vérifié que je pouvais gagner les longues minutes de purge de plus d’un millions de fichiers en supprimant directement le dossier session. Un rapide contrôle du trafic, des sessions et des commandes en cours : aïe, il y a trop de monde. Environ 200 sessions probables (selon temps de visite moyen) avec un taux de transformation de 6% et un panier moyen de 90€, ça me donne… 1080 € de pertes pour une simple commande rm -rf ! Un peu cher, je trouve. J’exécute donc une purge par date de fichiers et je laisse faire le serveur :

find . -atime +1 | xargs rm -f

90 minutes plus tard, tous les fichiers non utilisés depuis 48h sont supprimés (oui, +1 donne bien 2 jours, et non 1…). Je n’en ai plus « que » quelques milliers. Il reste à automatiser cette commande via crontab (en ajoutant les chemins absolus, bien entendu) et le tour est joué.

Sauf qu’il y a encore moyen d’améliorer tout ça, comme par exemple monter le dossier var de Magento en RAM. On gagne énormément en performances sur la gestions des sessions et du cache. Mais c’est une autre histoire…

Au passage , cette petite anecdote montre aussi qu’il ne faut jamais perdre de vue le métier de son client ou employeur. Certaines opérations menées sans réflexion et sans contrôle peuvent rapidement coûter très cher sur un site e-commerce. Il faut avoir en permanence le réflex d’évaluer la perte d’exploitation liée à une opération, même minime. En fin de mois, le cumul peut représenter bien plus que le salaire perçu…

Si l’activation du flat catalog est à peu près évidente (nous allons voir ça ci-après), il faut comprendre ce que fait Magento lorsqu’il crée les tables MySQL des produits à plat. Et on constate vite que, si on ne touche pas au paramétrage des attributs, on n’obtient pas du tout le résultat escompté !

Modèle EAV et flat catalog

Ce qui fait la souplesse de Magento, c’est la gestion de ses attributs par un modèle EAV. Chaque entité (produit, client, commande, etc.) est composée d’attributs (prix, couleur, pays, etc.) qui ont chacun une valeur (« 100 € », « vert », « France »). Comme un site évolue vite, on doit pouvoir ajouter ou retirer des attributs aux entités. Le modèle EAV est conçu pour cela, il permet de gérer facilement des attributs et leurs valeurs, sans modifier la structure de la base de données et sans écrire une seule ligne de code.

C’est un avantage énorme, mais il y a une contrainte de taille : quand Magento doit récupérer une entité (un produit par exemple), il doit parcourir un nombre important de tables dans la base de données pour assembler les valeurs des attributs et reconstituer l’information. Quand il faut afficher une page de catégorie avec 50 produits qui disposent chacun de 50 attributs, on arrive vite à la limite du tolérable. Comme le temps de réponse d’un site est le critère numéro 1 dans le succès d’un site e-commerce, il fallait trouver une réponse. Vous en réviez ? Magento le fait !

Pour accélérer les requêtes en lecture sur la base de données, Magento va construire de nouvelles tables dont chaque champ (ou colonne) représentera un attribut et chaque enregistrement (ou ligne) les valeurs des attributs d’une entité. C’est simple et rapide !

Bien entendu, si le catalogue est modifié, les tables doivent être reconstruites pour stocker les nouvelles informations. On ne met donc en œuvre des entités plates que si les valeurs ne changent pas tout le temps. Inutile d’y chercher les stocks ou les prix remisés par exemple.

Construire le flat catalog

Maintenant que les concepts de base sont posés, il faut savoir une chose : le flat catalog n’existe pas par défaut. Il faut donc le créer soit même depuis l’interface d’administration.

Pour créer un flat catalog :

• Menu Système > Gestion du cache
  
  Il faut d’abord construire les tables dans MySQL, grâce à ces boutons. On a le choix d’aplatir les catégories, les produits ou les deux.
• Menu Système > Configuration > Catalogue > Frontend
  
  Si nous ne construisons pas les tables via la gestion du cache, ces deux options sont indisponibles. Mais comme nous l’avons fait, nous avons maintenant le choix d’utiliser le flat catalog sur le frontend. Pourquoi faire compliqué alors qu’une seule étape pourrait suffire ? Simplement parce que Magento peut gérer plusieurs sites. On peut avoir un flat catalog sur un site et pas sur l’autre.
• Menu Système > Gestion du cache
  Oui, il faut y revenir pour ajouter nos entités (catégories et/ou produits) dans les tables à plat.

C’est tout. Mais est-ce suffisant ? Pas du tout ! Si on analyse les tables créées, on s’aperçoit vite que tous les attributs n’y sont pas, en particulier ceux spécifiques au site.

Si nous voulons afficher des valeurs d’attributs sans tuer les performances du serveur, il faut les ajouter à la structure des tables à plat. Pas de panique, inutile de faire ce sale boulot par des requêtes SQL hasardeuses. Magento a tout prévu… sauf de documenter ce détail essentiel !

Définir les attributs à aplatir

Quand nous demandons la construction du flat catalog, Magento utilise l’Indexer du module Catalog qui contient des contrôles sur la configuration des attributs (fichier Mage\Catalog\Model\Resource\Eav\Mysql4\Product\Flat\Indexer.php). Il contrôle notamment l’état du paramètre used_in_product_listing. S’il est égal à 1, l’attribut est intégré au flat catalog.

Reste à savoir d’où vient cet état. Une petite recherche (merci nWire !) et le voici, caché dans la configuration d’attribut (fichier Adminhtml\Block\Catalog\Product\Attribute\Edit\Tab\Main.php). On a la solution.

Pour ajouter un attribut dans le flat catalog :

• Menu Catalogue > Attributs > Gérer les attributs
  Sélectionner l’attribut à « aplatir ».
• Volet Propriétés du front-office
  
  C’est là que se cache l’option. Il faut choisir Oui et sauvegarder l’attribut.
• Menu Système > Gestion du cache
  On reconstruit le cache.

Le résultat est nettement meilleur. J’ai maintenant mon attribut dans mon flat catalog (ici manufacturer). Et un mystère de moins !

Magento est un bien joli projet qui peut maintenant servir de cas d’école pour les élèves ingénieurs. Son architecture objet complexe mais extensible offre un degré de personnalisation rarement vu dans une solution e-commerce.

Cependant, avoir une vision globale ou comprendre le comportement précis d’un module reste un exercice ardu. Surtout sans documentation de référence…

Heureusement, il existe toujours un outil fabuleux pour nous sauver la mise et, sur ce coup, c’est nWIRE for PHP qui s’y colle. Avec talent.

nWIRE analyse le code PHP et en extrait tous les composants et associations. Intégré à Eclipse, il offre une vue précise des éléments du code source, notamment sur des architectures purement objet comme Magento. Les grincheux vont me dire que l’UML est fait pour ça et que PHPDocumentor nous sort ces informations. Sauf que personne n’a réussi à le faire pour Magento, alors que nWIRE le fait en temps réel pendant le développement. Petit tour d’horizon.

Que fait nWIRE ?

nWIRE commence par analyser votre espace de travail pour indexer les éléments du code source et créer sa propre base d’informations. Chaque détail du code compte : déclaration de méthode, surcharge, invocation, instanciation, interface, sous-classes, commentaires normés, etc.

L’analyse en tâche de fond apporte un réel confort lors du développement (à condition d’avoir une machine qui supporte la lourdeur d’Eclipse…).

Un navigateur intuitif

Une fois l’analyse terminée, nWIRE Navigator prend le relais pour afficher toutes les informations qu’il possède sur un fichier ouvert. L’affichage s’adapte à la position du curseur dans le code, on obtient donc des informations contextuelles.

Le Navigator est bien sûr navigable. On peut facilement explorer les liens vers d’autres blocs de code appartenant à d’autres fichiers. Ceux-ci s’ouvriront à la volée dans Eclipse.

Le comportement est paramétrable, on peut alors se focaliser sur certains résultats pour éviter d’être noyé dans la masse d’informations.

Les schémas en prime

Des textes, c’est bien, mais un dessin, c’est mieux ! nWIRE Visualizer peut donc créer un graphique des relations, à partir de la sélection faite dans le navigateur. Cerise sur le gâteau, ce graphique n’est pas figé mais navigable, lui aussi !

La recherche n’est pas oubliée

Avoir un tel outil sans moteur de recherche serait une aberration. Donc il existe… et il est efficace ! Plus rapide et plus adaptée que celui d’Eclipse (Ctrl + H). De plus, il gère la complétion automatique afin de proposer des résultats, même quand vous ne connaissez pas bien les composants applicatifs.

En pratique, ça donne quoi ?

Commençons par un premier exemple. Je souhaite comprendre l’architecture du modèle de gestion des produits du catalogue.

J’ouvre le fichier app/code/core/Mage/Catalog/Model/Product/Type/Abstract.php.

nWIRE me donne les premières informations sur ce fichier qui contient la classe Mage_Catalog_Model_Product_Type_Abstract.

Si j’ouvre le contenu de cette classe, j’obtiens la liste des propriétés et méthodes avec un focus dans le code source du fichier ouvert. Ici, la méthode getSku() est sélectionnée.

Plus intéressant, je souhaite savoir quelles sont les sous-classes de Mage_Catalog_Model_Product_Type_Abstract. J’obtiens les types de produits Magento : Simple, Configurable, Grouped, Virtual, Bundle.

Tiens ? Au passage, on voit de suite que les produits de type Bundle sont gérés par un module spécifique. Voilà un cas particulier détecté en 5 secondes !

La première découverte étant faite, je souhaite la partager avec mes collègues. Un beau schéma ferait bien l’affaire.

Le premier essai n’est pas idéal. Aucun filtre n’est appliqué et le résultat est trop confus.

Après un petit passage dans les filtres, c’est nettement mieux ! J’ai ce qu’il me faut.

Si je navigue dedans, je peux avoir certains détails, comme ici les méthodes qui retournent l’objet sélectionné dans l’ensemble du code Magento. Très précieux pour comprendre certains comportements.

Autre exemple autour de la recherche : à quel moment Magento dispatche les événements ? On active le moteur de recherche, mot-clé dispatchEvent et c’est parti.

Parmi les entrées retournées (en moins d’une seconde, les habitués au moteur de recherche d’Eclipse apprécieront), la méthode Mage::dispatchEvent() m’intéresse. Je la sélectionne et nWIRE ouvre le fichier qui contient cet élément. J’ai donc une vision claire du traitement des événements.

Mais ce qui m’intéresse, c’est de savoir où est utilisée cette méthode dans Magento, je vais donc chercher son invocation. nWIRE me propose le lien Invoked by. J’obtiens immédiatement les 216 appels à cette méthode dans Magento.

Je n’ai plus qu’à vérifier que ces appels sont bien placés… ce qui n’est malheureusement pas le cas partout. nWIRE est donc aussi outil de déboguage efficace pour Varien !

Conclusion

C’est le genre d’outils payants (59 $) qui est rentabilisé dans la journée. Je travaille avec depuis une quinzaine de jours et j’avoue que ma compréhension de certaines subtilités (ou défauts) de Magento s’en trouve transformée. Indispensable dans la palette d’outils du développeur Magento.

Le Bargento 3, c’est dans 2 jours ! La journée s’annonce exceptionnelle avec plus de 300 participants, l’inauguration de la Magento Academy, un concours de programmation de widgets, des présentations d’extensions… Entre conférences, ateliers et discussions de couloir, je ne vois pas comment tout va tenir en 10h de temps, mais c’est la magie de l’événement.

Cette fois-ci, je n’anime pas d’atelier, mais j’accompagnerai l’AFUP, partenaire de l’événement, et son président, Xavier Gorse, pour organiser la journée et accueillir les participants.

Malgré ces annonces étourdissantes, il manquait un truc… Un truc que je n’ai pas trouvé en 2 ans d’existence de Magento. Comme j’ai du mal à travailler sans, j’ai fini par m’y mettre et un premier jet sera disponible dans quelques jours : un Guide de référence Magento.

Et comme Magento évolue très vite, il ne s’agit pas d’un livre en papier mais d’une application web qui utilise des technologies sémantiques. Première brique, le référentiel des fonctionnalités de Magento Community Edition permet de trouver n’importe quelle information détaillée concernant une fonctionnalité de Magento (comme par exemple, où elle se situe dans l’interface d’administration). Comme il a pour but d’aider les utilisateurs au quotidien, les outils proposés sont adaptés à une recherche rapide :

• Recherche plein texte
• Filtres à facettes hiérarchiques (plus fort que Magento !)
• Tris dynamiques
• Groupement des résultats

Qu’obtient-on à la sortie ? Un peu ce qu’on veut en fait. Quelques exemples :

• Je souhaite caler toutes les adresses e-mail de Magento. Je tape « e-mail » dans le moteur de recherche et j’obtiens toutes les fonctionnalités qui ont un rapport avec les e-mails.
• Je souhaite paramétrer ce qui concerne le profil local de la plate-forme. Je sélectionne le groupe fonctionnel « Internationalisation / Localisation » et j’ai la liste complète des points à traiter (voir écran ci-dessous).
• Je souhaite connaître toutes les fonctionnalités attachées à un menu Magento. Je choisis une entrée de menu Magento dans le filtre hiérarchique correspondant et j’ai une liste exhaustive.
• J’ai besoin de détails sur une fonctionnalité. J’ouvre le panneau des détails et je sais tout.
• Je souhaite avoir la liste de tous les boutons de l’interface d’administration de Magento. Je choisis l’élément IHM « bouton » comme filtre. Bon là, je ne vois pas à quoi cela peut servir mais ça sait le faire !

En résumé, c’est un outil très souple et rapide qui saura s’adapter à vos recherches. Dans un premier temps, le contenu sera assez léger, mais le but est de l’alimenter au fur et à mesure des retours d’expérience. J’ai même prévu des liens avec les meilleures astuces liées à une fonctionnalité de Magento !

C’est Noël avant l’heure. Pour la plaisir (et le buzz !), une petite copie d’écran :

A lundi pour une petite démo ?

Au rythme des versions de Magento, il devient difficile de suivre les modifications apportées au code source. Pourtant, ce suivi est obligatoire pour garantir la compatibilité des extensions ou des thèmes avec une nouvelle version.

Pour les extensions, les développeurs ont l’habitude de suivre les feuilles de route et les changelogs. Une nouvelle version de Magento appelle donc une nouvelle version de l’extension. C’est habituel.

Il en est tout autrement pour les thèmes. Chaque thème est souvent spécifique à un site e-commerce. En cas de mise à jour de Magento, il est possible que le thème par défaut change. Il faut donc répercuter ces modifications sur le thème spécifique, sinon c’est bugs garantis ! Et comme Magento regorge de fonctions Javascript et Ajax, il est parfois pénible de tout passer en revue.

Alors pour vous faciliter la tâche, je mets à disposition un « Comparateur des versions stables de Magento Community Edition ». Cet outil répertorie toutes les modifications du code source de Magento entre deux versions stables. C’est visuel, exhaustif et rapidement accessible. Le genre de truc qu’on utilise plusieurs fois par jour…

N’hésitez pas à donner votre avis pour améliorer la chose. Et après, j’ai des trucs encore plus dingues dans les cartons !

Détail d’un fichier modifié entre deux versions Magento, avec mise en évidence des lignes.

L’automne sera chargé en mises à jour Magento. Magento Enterprise Edition 1.6.0.0 sera lancé sous peu (la version RC 1 est disponible pour les partenaires depuis le 8 octobre). Quant à Magento Community Edition, il passera en version 1.4.0.0 avant Noël (I hope so, Yoav!).

Cette nouvelle série Magento va très vite creuser l’écart avec ses concurrents (mais aussi avec les anciennes séries Magento…), grâce à des fonctionnalités vraiment intéressantes. Outre le nouveau système de calcul de prix (dont les tests m’ont bien occupé au début de l’été), Magento intègrera également un moteur de widgets.

Des widgets, pour quoi faire

Les widgets sont partout dans les applications web aujourd’hui car ils permettent aux utilisateurs non techniciens d’ajouter des contenus dynamiques à leur site web. Plus besoin d’un développement avancé pour afficher la liste des 5 produits les plus vus de la semaine… même s’il faut des développeurs pour programmer les widgets qui feront cela ! Mais si les widgets sont suffisamment bien conçus, on pourra par exemple :

• placer des vidéos
• accéder à d’autres services web (réseaux sociaux, flux RSS, partenaires, etc.)
• afficher un nuage de tags
• lister les derniers commentaires
• classer les produits par avis des clients
• etc.

Comment créer un widget Magento ?

Les widgets Magento sont des blocs du frontend dont le comportement est défini dans l’interface d’administration. Ils doivent être développer selon la même approche que les modules Magento. Les développeurs Magento ne seront donc pas dépaysés, la logique reste la même : un dossier pour le widget avec sa configuration XML, son modèle métier, ses helpers et son activation dans app/etc/modules. Jusque là, rien de neuf.

La grosse différence est l’apparition d’un fichier widget.xml dans le dossier etc du module, à côté du config.xml. Il sert à déclarer le widget dans le moteur de widgets afin de le rendre disponible à l’utilisateur du backend.

Pour que le widget fonctionne, il doit implémenter une interface (dans le sens programmation orientée objet) pour gérer les flux de données (ajout, modification et accès) et afficher le résultat (méthode toHtml()).

Attention à faire un travail propre ! Toutes les méthodes de cette interfaces existent dans le noyau de Magento dans des classes abstraites. On peut donc tirer bon avantage à les utiliser pour fiabiliser le rendu final. Le premier didacticiel sur le site officiel est très clair sur ce point.

Comment utiliser un widget Magento ?

Une fois programmé et correctement installé, le widget est accessible via le module wysiwyg. Ah oui, j’ai oublié de le dire : Magento intègrera désormais un module wysiwyg en standard. Un progrès notable !

La suite est tellement simple que je ne vois pas l’intérêt d’expliquer comment s’en servir…

Pour conclure

Je vois un énorme avantage avec l’arrivée des widgets : de nombreuses extensions vont pouvoir disparaître et simplifier le travail de développement et d’intégration des sites. Sans oublier que ce ménage salvateur va fiabiliser la plate-forme. Je suis content de cette série 1.4, vraiment content !

Pour aller plus loin

• Introducing Magento Widgets
• Tutorial: Creating a Magento Widget, Part 1
• Tutorial: Creating a Magento Widget, Part 2

Si on utilise le profil d’importation CSV standard de Magento, un fichier de comptes clients contient une ligne par compte avec l’ensemble des valeurs de ses attributs. Parmi ces champs, se trouve l’état d’abonnement à la newsletter. Lors d’une migration d’un site existant vers une plate-forme Magento, il est donc possible d’avoir des milliers de comptes dont la majorité sont abonnés à la newsletter.

Pendant l’importation de ces données, Magento utilise son modèle métier pour valider chaque ligne et réaliser l’action adéquate : création ou modification. Le problème pour les nouveaux comptes ou pour ceux dont l’abonnement à la newsletter change, c’est qu’ils seront traités comme le fait l’interface d’administration : un message sera envoyé au client pour l’avertir du changement d’état de l’abonnement.

Si votre fichier contient 50000 comptes, ce sont potentiellement 50000 e-mails qui partent lors de l’importation ! Retours garanties…

Donc si vous faites des importations de comptes clients, prenez vos précautions (en coupant le serveur SMTP par exemple), surtout si l’importation se répète plusieurs fois par jour lors des tests fonctionnels ou des tests de charge. Situation vécue…