Audit des modules Magento 2 : comment vérifier quelles extensions aident la boutique et lesquelles la ralentissent ?

Magento 2 offre une grande liberté pour faire évoluer une boutique, mais avec le temps, cette flexibilité peut devenir un problème. Chaque module ajoute de nouvelles fonctionnalités, mais il peut aussi avoir un impact sur les performances, la sécurité, le processus de mise à jour et les coûts de maintenance. C’est pourquoi un audit régulier des extensions devrait faire partie des éléments essentiels de la maintenance d’une boutique Magento.

Dans cet article, nous expliquons quand il est judicieux de réaliser un audit des modules Magento 2, ce qu’il faut vérifier précisément et comment décider quelles extensions conserver, mettre à jour, remplacer ou supprimer.

Conclusion principale : les modules Magento 2 n’apportent de la valeur que s’ils sont nécessaires, à jour et cohérents avec l’architecture de la boutique. Une extension que personne n’utilise ou que personne ne met à jour devient une dette technique.

Pourquoi l’audit des modules dans Magento 2 est-il important ?

Dans de nombreuses boutiques Magento 2, la liste des extensions installées s’allonge progressivement. On ajoute d’abord un module d’avis, puis une intégration avec un transporteur, des champs supplémentaires dans le checkout, un outil SEO, un flux produit, une newsletter, l’automatisation des promotions, des fonctionnalités B2B, des intégrations avec des marketplace et d’autres solutions déployées à la hâte.

Le problème apparaît au bout de quelques années. Certains modules restent critiques pour les ventes, mais d’autres :

• ne sont plus utilisés,
• dupliquent les fonctionnalités d’autres extensions,
• ne sont pas compatibles avec la version actuelle de Magento,
• ralentissent le panneau d’administration ou le frontend,
• compliquent les mises à jour,
• génèrent des erreurs dans les logs,
• augmentent le coût de maintenance de la boutique.

L’audit permet de distinguer les modules réellement nécessaires de ceux qui sont restés dans le système uniquement parce que personne ne les avait examinés auparavant.

Quand faut-il réaliser un audit des extensions Magento ?

Il est particulièrement utile de réaliser un audit des modules avant des changements techniques ou commerciaux importants. Les moments les plus fréquents sont :

• la mise à jour de Magento vers une version plus récente,
• la migration vers un nouvel hébergement,
• le déploiement du thème Hyva ou la refonte du frontend,
• une baisse des performances de la boutique,
• des problèmes dans le checkout,
• une hausse des coûts de maintenance,
• la reprise de la boutique après une autre agence,
• l’extension de la boutique au B2B, aux marketplace ou à la vente internationale,
• la préparation de la boutique à une période de forte activité commerciale.

Un autre signal d’alerte est une situation où l’équipe technique craint les mises à jour parce que l’on ne sait pas ce qui va casser. Cela signifie généralement que les dépendances de la boutique doivent être remises en ordre.

Que vérifier lors d’un audit des modules Magento 2 ?

L’audit ne doit pas se limiter à la simple liste des modules obtenue avec la commande bin/magento module:status. La seule présence d’un module ne dit pas encore s’il est nécessaire, correctement utilisé et sécurisé.

En pratique, il est utile de vérifier plusieurs domaines : l’usage métier du module, son impact sur les performances, la sécurité, la compatibilité avec la version actuelle de Magento, les dépendances dans Composer ainsi que le risque lors des prochaines mises à jour.

À quoi ressemble un audit des modules Magento 2 étape par étape ?

Un bon audit commence par un inventaire. Il faut d’abord déterminer quels modules sont actifs, d’où ils proviennent et à quoi ils servent. En pratique, il est recommandé de comparer plusieurs sources :

• la liste des modules actifs issue de bin/magento module:status,
• le fichier app/etc/config,
• les dépendances dans composer.json et composer.lock,
• les répertoires app/code, vendor ainsi que les éventuels modules installés manuellement,
• la configuration dans le panneau d’administration,
• les logs Magento, PHP et serveur,
• les tâches cron et les intégrations externes.

L’étape suivante consiste à attribuer un rôle aux modules. On n’évalue pas de la même manière une extension responsable du checkout, un module SEO ou une intégration avec un ERP. Un module qui modifie le processus de commande présente un risque de régression nettement plus élevé qu’une extension qui ajoute un simple bloc d’information sur la page produit.

Il est également utile de vérifier si le module a un propriétaire métier. Si personne dans l’entreprise ne sait dire pourquoi une extension donnée fonctionne dans la boutique, c’est un signal qu’une vérification plus approfondie est nécessaire. Cela ne signifie pas automatiquement que le module doit être supprimé, mais cela indique que son rôle n’est pas bien documenté.

Un processus d’audit pratique peut se présenter ainsi :

1. recueillir la liste des modules et des sources d’installation,
2. décrire la fonction de chaque extension,
3. vérifier si la fonction est encore utilisée,
4. évaluer l’impact sur le frontend, le backend, le checkout, le cron et les intégrations,
5. vérifier la compatibilité avec la version de Magento, PHP et le thème,
6. examiner les erreurs dans les logs et les signalements des utilisateurs,
7. attribuer au module un statut : conserver, mettre à jour, remplacer ou supprimer,
8. préparer un plan de changements sur l’environnement de test.

Ce processus est plus simple qu’un audit complet du code, mais il fournit déjà beaucoup d’informations. Il permet de voir rapidement quelles extensions sont critiques, lesquelles ne sont qu’un complément et lesquelles créent un risque inutile.

Tableau d’évaluation d’un module Magento 2

Lorsqu’il y a beaucoup d’extensions, il est utile de tenir un tableau d’audit simple. Il n’a pas besoin d’être compliqué. L’essentiel est qu’il aide à prendre des décisions et qu’il soit compréhensible à la fois pour la personne technique et pour le propriétaire de la boutique.

1. Le module est-il réellement utilisé ?

La première question est simple : la boutique utilise-t-elle encore la fonctionnalité de cette extension ?

Il est utile d’examiner :

• la configuration dans le panneau d’administration,
• les éléments visibles sur le frontend,
• les dépendances dans le checkout,
• les tâches cron,
• les intégrations API,
• les exports et imports,
• les templates e-mail,
• les règles commerciales,
• les attributs personnalisés de produits ou de clients.

Il arrive souvent qu’un module ait été installé pour un test, une campagne ou une ancienne intégration, mais qu’il n’ait plus aucune importance pour les ventes depuis longtemps. Un exemple typique est une extension destinée à un export de données unique, qui est restée active dans le système après une migration, alors que plus personne ne l’utilise.

Il faut rester prudent avec les modules dont la fonction n’est pas immédiatement visible sur le frontend. Une extension peut fonctionner uniquement en arrière-plan : synchroniser les stocks, envoyer des données vers un ERP, modifier des prix contractuels ou ajouter des attributs utilisés par une intégration. C’est pourquoi la décision de suppression ne doit pas reposer uniquement sur le fait qu’on ne la voit pas sur le site.

2. Le module ne duplique-t-il pas la fonction d’une autre solution ?

Dans Magento, il est facile d’en arriver à une situation où plusieurs modules couvrent un domaine similaire. Exemples :

• deux modules SEO qui modifient les métadonnées,
• plusieurs extensions qui interviennent dans le checkout,
• des modules distincts pour les avis, les rich snippets et schema.org,
• différentes intégrations qui exportent les données produit,
• plusieurs outils qui ajoutent des scripts au site.

Ce type de duplication augmente le risque de conflits. Même si la boutique fonctionne correctement, le problème peut n’apparaître qu’après une mise à jour de Magento, un changement de thème ou le déploiement d’une nouvelle version de PHP.

Le domaine SEO en est un bon exemple. Un module peut gérer les métadonnées, un deuxième les canonicales, un troisième les données structurées et un quatrième le plan du site. Si chacun modifie des éléments HTML similaires, la boutique peut générer des balises contradictoires ou des résultats imprévisibles après un changement de configuration. L’audit doit alors indiquer quel module constitue la source de vérité pour le domaine concerné.

3. Le module influence-t-il les performances ?

Tous les problèmes de performances ne viennent pas du serveur. Les modules peuvent solliciter la boutique de nombreuses manières :

• ils exécutent des requêtes SQL lourdes,
• ils vident le cache trop souvent,
• ils génèrent des blocs inutiles sur chaque page,
• ils ajoutent beaucoup de fichiers JS et CSS,
• ils ralentissent l’indexation,
• ils créent trop de tâches cron,
• ils alourdissent le panneau d’administration,
• ils exécutent des requêtes API externes pendant le chargement de la page.

Dans l’audit, il est utile de vérifier séparément le frontend, le backend, le cron, l’indexation et le checkout. Un module qui n’a pas d’impact visible sur la page d’accueil peut quand même provoquer des problèmes lors de la commande ou de l’édition massive de produits.

Pour analyser les performances, il ne suffit pas de vérifier uniquement le PageSpeed de la page d’accueil. Dans une boutique Magento, les scénarios sont plus pertinents : accéder à une catégorie avec filtres, consulter une fiche produit avec variantes, ajouter au panier, passer par le checkout, enregistrer un produit dans le panneau, importer des données, indexer et exécuter les tâches cron. Ce n’est qu’à ce moment que l’on voit si le problème concerne le frontend, les requêtes vers la base de données, une API externe ou la logique du module.

Si la boutique utilise des outils comme New Relic, Blackfire, le profiler Magento ou un monitoring des requêtes SQL, il est utile de rapprocher les résultats de la liste des extensions actives. Un module qui exécute de nombreuses requêtes sur chaque page de catégorie peut être plus problématique qu’une extension visible sur le frontend, mais correctement mise en cache.

4. Le module est-il mis à jour et compatible ?

Une extension Magento doit être maintenue. Si un module n’a pas été mis à jour depuis plusieurs années, il faut le considérer comme un risque technique.

Il est utile de vérifier :

• la compatibilité avec la version actuelle de Magento,
• la compatibilité avec la version de PHP utilisée,
• la disponibilité des mises à jour via Composer,
• l’historique des changements,
• les correctifs de sécurité,
• la compatibilité avec le thème actuel,
• la compatibilité avec Hyva, si la boutique utilise ou prévoit d’utiliser ce frontend.

L’absence de mise à jour ne signifie pas toujours qu’il faut supprimer immédiatement le module, mais elle doit déclencher une question : cette fonction est-elle suffisamment importante pour continuer à la maintenir ?

Dans l’audit, il est utile de distinguer trois situations. Premièrement : le module est à jour et sa compatibilité avec la version de Magento utilisée est clairement établie. Deuxièmement : le module dispose de mises à jour, mais la boutique fonctionne sur une version plus ancienne. Troisièmement : le module n’est plus développé ou son éditeur ne déclare pas de compatibilité avec les versions actuelles de Magento et PHP. Ce dernier groupe nécessite généralement un plan de remplacement ou des tests supplémentaires avant chaque changement majeur.

5. Le module est-il sécurisé ?

Les modules Magento peuvent traiter des données clients, des commandes, des paiements, des formulaires, des fichiers, des intégrations API et le panneau d’administration. La sécurité des extensions est donc aussi importante que celle de Magento lui-même.

Lors de l’audit, il est utile de vérifier :

• si le module ajoute ses propres endpoints,
• s’il possède des formulaires accessibles publiquement,
• s’il utilise l’upload de fichiers,
• s’il enregistre des tokens API,
• s’il étend le panneau d’administration,
• s’il dispose de ses propres droits ACL,
• s’il ne contourne pas les mécanismes standard de validation Magento.

Une attention particulière doit être accordée aux modules qui ne proviennent pas d’une source de confiance ou qui ont été modifiés manuellement sans documentation.

Il est également utile de vérifier si le module n’enregistre pas de données sensibles dans les logs ou dans la configuration d’une manière qui complique le contrôle des accès. Cela concerne surtout les intégrations avec les paiements, les ERP, les marketplace, les outils AI, les passerelles SMS et les services d’expédition. Un token API enregistré au mauvais endroit peut représenter un risque plus important que la fonction du module elle-même.

6. Le module augmente-t-il les coûts de maintenance ?

Le coût d’un module ne se limite pas à son prix d’achat. Au coût réel, il faut ajouter :

• le temps de mise à jour,
• les tests de régression,
• les conflits avec d’autres extensions,
• les correctifs après des changements dans Magento,
• la dépendance à des services externes,
• le temps de gestion de la configuration,
• le support technique,
• le risque d’interruption.

Parfois, un module moins cher s’avère plus coûteux à maintenir qu’une solution mieux adaptée à l’architecture de la boutique. Il faut considérer le coût total de possession, et pas seulement le prix de la licence.

Le coût augmente particulièrement lorsque le module nécessite des contournements manuels à chaque mise à jour. Si l’extension doit être régulièrement corrigée après un changement de version de Magento, PHP, ElasticSearch/OpenSearch ou du thème, son prix réel inclut aussi le temps du développeur et du testeur. Dans ce cas, l’audit doit montrer s’il est plus rentable de maintenir la solution actuelle ou de planifier son remplacement.

Différents types de modules nécessitent une évaluation différente

Toutes les extensions Magento n’ont pas le même impact sur la boutique. C’est pourquoi il est utile de les répartir en plusieurs groupes lors de l’audit.

Les modules frontend influencent l’apparence de la boutique, le layout, les fichiers .phtml, JavaScript, CSS, les blocs et les éléments de la page produit ou catégorie. Pour ces modules, il faut vérifier les performances, la compatibilité avec le thème et l’impact sur les Core Web Vitals.

Les modules de checkout et de paiement sont les plus sensibles d’un point de vue commercial. Toute modification dans ce domaine peut influencer la conversion et la passation des commandes. Ces extensions exigent des tests des scénarios d’achat, des modes de livraison, des paiements, des remises, des taxes et des commandes invités.

Les modules backend n’ont souvent pas d’impact direct sur le client, mais ils déterminent l’efficacité de l’équipe. Si un module ralentit la grille des commandes, l’enregistrement d’un produit ou les actions de masse, le coût se manifeste chaque jour dans le travail des administrateurs.

Les modules d’intégration connectent Magento à un ERP, un PIM, un WMS, des marketplace, des transporteurs, des systèmes de facturation ou des outils marketing. Pour eux, les logs, les retries, la gestion des erreurs, les files d’attente, les limites API et la résistance à l’indisponibilité du système externe sont essentiels.

Les modules SEO et de contenu nécessitent de vérifier leur impact sur l’indexation, les canonicales, les métadonnées, schema.org, les plans de site, les hreflang et les redirections. Ici, les erreurs peuvent ne pas être visibles immédiatement, mais se répercuter avec le temps sur le trafic organique.

Cette division aide à fixer les priorités. Un module de checkout a généralement une priorité de test plus élevée qu’un module ajoutant une simple étiquette sur une fiche produit. Une intégration ERP exige une évaluation différente de celle d’une extension pour un simple popup marketing.

Comment prendre la décision : conserver, mettre à jour, remplacer ou supprimer ?

Après l’audit, chaque module peut être classé dans l’un de ces quatre groupes.

Conserver

Le module est utilisé, stable, compatible avec la version de Magento et soutient un processus métier important. Il est préférable de le conserver, tout en continuant à documenter son rôle.

Exemple : un module d’intégration avec un système ERP synchronise les stocks et les prix, fonctionne via une file d’attente, dispose d’une version actuelle et ne génère pas d’erreurs dans les logs. Même s’il n’est pas visible pour le client, il est critique pour les ventes et doit rester dans le système.

Mettre à jour

Le module est nécessaire, mais fonctionne dans une version plus ancienne. Il faut vérifier le changelog, effectuer la mise à jour sur un environnement de test et tester les processus clés.

Exemple : un module de paiement dispose d’une nouvelle version avec des correctifs de compatibilité pour la version actuelle de Magento et PHP. Il n’est pas pertinent de le supprimer, mais conserver l’ancienne version augmente le risque de problèmes lors des prochaines mises à jour.

Remplacer

Le module remplit une fonction importante, mais il est problématique : il ralentit la boutique, n’est plus développé ou complique les mises à jour. Dans ce cas, une meilleure solution peut être de migrer vers une autre extension ou d’implémenter la fonction de manière plus contrôlée.

Exemple : un module SEO génère les données structurées nécessaires, mais il surcharge en même temps de nombreux éléments de layout, entre en conflit avec le thème et ne reçoit plus de mises à jour. La fonction est nécessaire, mais cette extension précise n’est peut-être pas le meilleur moyen de la maintenir.

Supprimer

Le module n’est pas utilisé, duplique d’autres fonctions ou génère un risque supérieur au bénéfice. Sa suppression doit être précédée d’une vérification des dépendances, de la configuration, des données en base et de l’impact sur le frontend.

Exemple : un module destiné à un import unique de produits a été utilisé lors d’une migration, n’est plus exécuté, n’a pas de propriétaire métier et ajoute toujours des entrées dans le panneau d’administration. Après vérification des dépendances, sa suppression peut être planifiée.

Pourquoi ne faut-il pas supprimer les modules à l’aveugle ?

La simple désactivation d’un module peut ne pas suffire. Certaines extensions ajoutent :

• des tables dans la base de données,
• des attributs produits,
• des attributs clients,
• des colonnes dans des tables existantes,
• des entrées de configuration,
• des tâches cron,
• du layout XML,
• des templates e-mail,
• des intégrations avec des systèmes externes.

C’est pourquoi la suppression d’un module doit d’abord être réalisée sur un environnement de test. Après le changement, il faut vérifier le panneau d’administration, le frontend, le panier, le checkout, les paiements, l’expédition, l’indexation, le cache et les logs.

Il faut également vérifier si le module n’a pas laissé des données encore utilisées par d’autres processus. Il peut s’agir par exemple d’attributs produits utilisés dans des flux, de champs clients supplémentaires utilisés dans une intégration B2B ou de tables historiques de commandes nécessaires au reporting. Parfois, le module peut être désactivé, mais les données ne doivent pas être supprimées immédiatement.

Audit des modules et mise à jour Magento

Plus il y a de modules non organisés, plus la mise à jour de Magento est difficile. Chaque extension peut avoir ses propres dépendances, préférences, plugins, observateurs d’événements et surcharges de templates.

Un audit bien réalisé avant une mise à jour permet de :

• réduire le temps de développement,
• limiter le nombre de conflits,
• réduire le risque d’erreurs après le déploiement,
• simplifier les tests,
• améliorer la stabilité de la boutique,
• mieux planifier le budget.

Dans de nombreux cas, une partie des problèmes de mise à jour ne vient pas de Magento, mais des extensions ajoutées pendant des années sans plan global.

Avant une mise à jour, il est utile de préparer une courte cartographie des risques. Les modules qui interviennent dans le checkout, les paiements, les prix, le panier, l’indexation, l’API et le panneau d’administration doivent figurer sur la liste des tests prioritaires. Les extensions purement présentationnelles peuvent être testées plus tard, mais il faut tout de même vérifier qu’elles ne bloquent pas la compilation, le deployment ou la génération des ressources statiques.

Audit des modules et Hyva

Si la boutique prévoit de déployer Hyva, l’audit des modules est particulièrement important. Toutes les extensions créées pour le frontend standard de Magento ne fonctionneront pas correctement avec Hyvä sans couche de compatibilité supplémentaire.

Il est utile de vérifier :

• si le module intervient dans le frontend,
• s’il possède ses propres fichiers .phtml,
• s’il utilise RequireJS, Knockout ou UI Components,
• si l’éditeur propose une compatibilité avec Hyva,
• si un module compatibility distinct sera nécessaire,
• si la fonctionnalité reste nécessaire après la refonte du template.

C’est un bon moment pour simplifier la boutique et ne conserver que les extensions qui soutiennent réellement les ventes.

Avec Hyva, les modules qui s’appuyaient auparavant sur les mécanismes frontend standard de Magento, comme RequireJS, Knockout ou UI Components, sont particulièrement importants. Certaines fonctions peuvent être réécrites plus simplement, certaines nécessitent un module de compatibilité, et d’autres peuvent s’avérer inutiles après la refonte du template. Un audit avant le déploiement de Hyvä permet d’éviter de transférer les anciens problèmes vers le nouveau frontend.

Que doit-il rester après l’audit ?

L’audit des modules doit se terminer par un document de travail, et pas seulement par une discussion ou une liste de remarques dispersées. Idéalement, l’examen doit laisser un tableau avec les décisions et le plan d’action.

Une bonne documentation après l’audit doit contenir :

• la liste complète des modules,
• la source d’installation de chaque module,
• la description de la fonction métier,
• l’information indiquant si le module est utilisé,
• les zones d’impact : frontend, backend, checkout, cron, intégrations, SEO,
• l’évaluation du risque,
• la recommandation : conserver, mettre à jour, remplacer ou supprimer,
• la priorité de l’action,
• les notes pour les tests de régression,
• le propriétaire de la décision côté métier ou technique.

Un tel document facilite fortement les prochaines mises à jour Magento. L’équipe n’a pas besoin de redécouvrir à chaque fois à quoi sert une extension donnée ni si elle peut être modifiée. Il suffit de revenir à l’évaluation précédente et de la compléter avec les nouvelles informations.

Exemple : comment évaluer trois modules différents ?

Supposons que trois extensions fonctionnent dans la boutique : un module SEO, un module de checkout et un module d’intégration ERP. Chacun nécessite une approche différente.

Le module SEO doit être vérifié sous l’angle des métadonnées, des canonicales, des données structurées, du plan du site, des redirections et de l’impact sur l’indexation. Une erreur dans ce domaine peut ne pas arrêter les ventes immédiatement, mais réduire avec le temps la visibilité de la boutique dans Google.

Le module de checkout exige des tests d’achat. Il faut parcourir différentes combinaisons : client connecté et non connecté, différents modes de paiement, livraisons, coupons de réduction, produits simples et configurables, différents pays de livraison, différents taux de TVA. Ici, même un petit conflit peut directement réduire la conversion.

Le module d’intégration ERP doit être évalué sous l’angle de la stabilité des échanges de données. Les files d’attente, les logs, la gestion des erreurs, les nouvelles tentatives, les limites API et la cohérence des données sont essentiels. Si l’intégration fonctionne avec retard ou ne gère pas les erreurs, la boutique peut vendre des produits avec un stock obsolète ou un prix incorrect.

Cet exemple montre bien pourquoi l’audit des modules Magento 2 ne peut pas se limiter à une liste technique d’extensions. Chaque module a un impact différent sur les ventes, le SEO, le service client et le travail quotidien de l’équipe.

À quelle fréquence réaliser un audit des modules ?

Dans une boutique Magento 2, il est utile de réaliser un audit des modules au moins une fois par an. Il devrait en outre être une étape obligatoire avant des changements techniques majeurs.

Pour les boutiques développées de manière intensive, une revue plus courte chaque trimestre est une bonne solution. Il ne s’agit pas forcément d’un audit complet, mais il est utile de vérifier régulièrement si les nouveaux modules sont documentés, à jour et réellement nécessaires.

En pratique, une bonne norme consiste aussi à ajouter chaque nouveau module à la documentation dès son déploiement. Ainsi, l’audit annuel ne consiste pas à redécouvrir l’historique de la boutique depuis zéro, mais à mettre à jour les connaissances existantes.

Audit des modules Magento 2 avec l’aide d’un spécialiste

Dans une boutique simple, une partie de l’audit peut être réalisée en interne : vérifier la liste des modules, examiner la configuration et déterminer quelles fonctions sont utilisées. Dans les déploiements plus importants, il est toutefois préférable de combiner la perspective métier avec une analyse technique du code, des dépendances, des logs, des performances et de la compatibilité.

Kowal.store travaille avec les modules Magento 2, l’installation via Composer, la compatibilité avec les thèmes et la maintenance de boutiques basées sur Magento. Si la boutique nécessite une remise en ordre des extensions avant une mise à jour, une migration d’hébergement, un déploiement Hyva ou une refonte plus importante, l’audit des modules peut être une bonne première étape pour réduire les risques.

Un tel audit aide non seulement à trouver les extensions inutiles, mais aussi à mieux planifier l’évolution de la boutique : quelles fonctions conserver dans Magento, lesquelles remplacer par d’autres modules et lesquelles transférer vers des outils externes.

Résumé

Les modules Magento 2 sont l’une des grandes forces de cette plateforme, mais seulement lorsqu’ils sont choisis et maintenus de manière réfléchie. Un trop grand nombre d’extensions ajoutées au hasard peut ralentir la boutique, compliquer les mises à jour, augmenter les coûts et créer des risques de sécurité.

Un audit régulier permet de reprendre le contrôle de l’architecture de la boutique. Il aide à déterminer quels modules sont nécessaires, lesquels doivent être mis à jour, lesquels méritent d’être remplacés et lesquels peuvent être supprimés en toute sécurité.

Si une boutique Magento fonctionne depuis plusieurs années, a été développée par différentes équipes ou s’apprête à subir une mise à jour importante, l’audit des modules est l’une des meilleures premières étapes pour remettre la plateforme en ordre.