Windows Loader v2.2.2 traîne depuis des années dans les forums et les sites de téléchargement comme un vieux fantôme de l’ère Windows 7. Officiellement, il se présente comme un outil d’activation capable de transformer une installation en version d’essai en système prétendument « authentique », sans passer par une licence Windows achetée. Officieusement, il reste surtout classé dans la catégorie des logiciels pirates, avec tout ce que cela implique en matière de problèmes de légalité, de fiabilité et de sécurité informatique.
Pour beaucoup d’administrateurs système et de bidouilleurs, ce loader fait partie de la même galaxie que KMSPico, KMSAuto et consorts. Tous reposent sur une idée simple : automatiser un contournement de l’activation Windows, ici centré presque exclusivement sur Windows 7 et quelques éditions de Windows Server. Le marketing sauvage qui l’entoure le présente parfois comme « le meilleur moyen de passer WAT », en référence aux technologies d’activation de Microsoft. Dans la pratique, le fonctionnement réel et les risques associés restent très mal compris, surtout quand on voit encore en 2025 des tutos qui expliquent tranquillement comment désactiver l’antivirus pour lancer l’exécutable.
Pour un lecteur orienté infra ou sécurité, l’enjeu n’est pas de trouver une astuce de plus pour esquiver un achat de licence. L’enjeu, c’est de comprendre comment cet exécutable manipule le boot, quelles traces il laisse, comment il se compare aux mécanismes officiels comme KMS ou les clés OEM, et pourquoi les antivirus l’identifient quasi systématiquement comme logiciel controversé voire cheval de Troie. Un cas concret aide à y voir clair : une petite PME, que l’on appellera Atelier Duverne, a hérité d’un parc sous Windows 7 activé via Windows Loader. Quelques années plus tard, migration, audit de conformité et durcissement de l’AD se retrouvent plombés par ces activations bricolées. Impossible de faire comme si de rien n’était.
Ce type de situation résume l’intérêt du sujet : comprendre ce que fait réellement Windows Loader v2.2.2, comment il se propage dans les environnements, quels signaux techniques trahissent sa présence et, surtout, comment nettoyer et remettre d’équerre des postes qui en dépendent encore. Le débat légal existe, mais c’est souvent la surface visible d’un problème bien plus pénible : un socle Windows bancal, difficile à migrer, impossible à auditer proprement.
En bref
- Windows Loader v2.2.2 est un outil d’activation non officiel ciblant principalement Windows 7 et certains Windows Server, en injectant un faux SLIC dans le démarrage.
- Son usage repose sur un contournement de l’activation Windows mis en place par Microsoft WAT, ce qui en fait un logiciel pirate avec des problèmes de légalité évidents.
- Le programme est souvent présenté comme « hors ligne », « à vie » et « sans .NET Framework », ce qui attire les homelabs et les parcs vieillissants.
- Les antivirus le détectent régulièrement comme cheval de Troie ou outil de piratage, même quand le binaire n’embarque pas de charge malveillante visible.
- En contexte pro, le garder en production bloque les audits, complique les migrations et ouvre un vrai sujet de sécurité informatique et de conformité.
Windows Loader v2.2.2 : fonctionnement technique et périmètre réel de l’outil d’activation
Pour comprendre pourquoi Windows Loader fascine autant, il faut regarder comment il approche l’activation Windows. Contrairement aux outils basés sur KMS qui simulent un serveur d’activation réseau, cette application joue plutôt sur le mode OEM historique. En clair, elle injecte un faux bloc SLIC (Software Licensing Description Table) dans le processus de démarrage, de façon à faire croire au système qu’il tourne sur un matériel OEM déclaré comme licencié.
Concrètement, Windows Loader v2.2.2 cible surtout :
- les éditions de Windows 7 (Starter, Home, Professional, Ultimate, etc.)
- plusieurs versions de Windows Server 2008 / 2008 R2
- et, dans cette révision 2.2.2, un support étendu à Windows Server 2012 R2
Il ne gère pas les familles Windows 8, 10 ou 11, contrairement à ce que laissent parfois entendre des sites peu regardants. Son champ d’action reste donc concentré sur un parc déjà ancien, mais encore présent dans pas mal de TPE/PME et de machines industrielles difficiles à migrer.
L’outil se présente souvent sous la forme d’un exécutable unique, lancé avec des droits administrateur. En interne, il intervient avant le chargement complet du système pour :
- modifier la chaîne de démarrage afin d’injecter une table SLIC factice en mémoire
- associer cette table à un certificat OEM et une clé produit correspondante
- faire accepter à WAT cette configuration comme légitime
Résultat : dans le panneau Système, le poste apparaît comme « Windows est activé », avec un ID de produit similaire à celui d’un PC de marque livrée avec une clé OEM. Beaucoup d’utilisateurs s’arrêtent là, sans mesurer que le socle d’activation repose en réalité sur un bricolage très éloigné des mécanismes prévus par Microsoft.
Les auteurs de Windows Loader v2.2.2 mettent en avant plusieurs caractéristiques pour séduire les utilisateurs avancés :
- Activation hors ligne : aucun besoin de contacter un serveur d’activation, ce qui attire les machines isolées du réseau ou les homelabs non connectés.
- Activation « à vie » : le principe OEM simulé contourne la durée limitée classique des activations basées sur KMS.
- Absence de dépendance à .NET Framework : le loader tourne sur des installations Windows 7 nues, sans importer de runtime supplémentaire.
Sur le papier, l’outil semble donc séduisant pour redonner vie à de vieilles machines. Dans la pratique, il modifie un point sensible de la chaîne de démarrage, ce qui complique énormément les diagnostics ultérieurs. Un technicien qui se retrouve face à un BSOD ou un bootloop sur un poste « patché » par Windows Loader va devoir intégrer ce paramètre dans son enquête, ce qui n’est jamais neutre.
| Élément | Comportement avec Windows Loader v2.2.2 | Comportement avec une licence Windows légitime |
|---|---|---|
| Mécanisme d’activation Windows | Simulation d’un environnement OEM via faux SLIC injecté au démarrage | Clé produit valide enregistrée dans la base de licence Microsoft (OEM, Retail, Volume, KMS) |
| Connexion à Internet | Non obligatoire, activation hors ligne possible | Souvent nécessaire pour l’activation et la validation périodique |
| Compatibilité versions | Principalement Windows 7 et certains Windows Server jusqu’à 2012 R2 | Toutes les versions supportées selon la clé achetée |
| Visibilité lors d’un audit | Activation non traçable dans les canaux officiels, incohérences possibles dans les inventaires | Activation visible et vérifiable via les outils Microsoft et les portails de gestion de licences |
| Maintenance à long terme | Risque lors des mises à jour majeures, diagnostics compliqués | Support aligné sur le cycle de vie Microsoft, comportement documenté |
Dans un environnement professionnel comme celui d’Atelier Duverne, cette différence se manifeste très vite. Les outils d’inventaire SAM renvoient des activations incohérentes, les mises à niveau vers Windows 10 échouent sur quelques postes, et certains écrans bleus récurrents disparaissent mystérieusement quand on réinstalle proprement le système avec une clé valide. La conclusion technique tombe : tout ce qui touche au boot et aux mécanismes de licence mérite de rester dans le périmètre des outils officiels.
Téléchargement de Windows Loader et scénarios d’usage : ce que racontent vraiment les tutos
Une grosse partie de l’aura de Windows Loader vient des tutoriels de téléchargement qui se promènent encore sur le web. Ils suivent souvent la même trame : lien vers un hébergement type Mega, archive protégée par mot de passe, consigne explicite de désactiver l’antivirus ou Windows Defender, extraction avec WinRAR, puis exécution de Windows Loader.exe en tant qu’administrateur.
Un guide typique enchaîne généralement les étapes suivantes :
- cliquer sur un bouton « Télécharger Windows Loader par DAZ » conduisant à un miroir tiers
- récupérer une archive dans le dossier Téléchargements, souvent protégée par un mot de passe simple type « windows »
- désactiver l’antivirus et la protection en temps réel, via Windows Defender ou une solution tierce
- extraire l’exécutable puis lancer le loader avec les droits administrateur
- cliquer sur « Install », redémarrer, vérifier que « Windows est activé » dans le Panneau de configuration
Sur le plan strictement technique, chaque étape a une logique. L’archive compressée permet de contourner certains filtres de téléchargement, le mot de passe évite une analyse automatique par les scanners antivirus, et la désactivation de la protection en temps réel répond au fait que l’outil est systématiquement catégorisé comme logiciel pirate ou outil de piratage. Tous les signaux d’alerte typiques d’un scénario de compromission sont réunis.
Les variantes les plus « rassurantes » de ces tutos insistent sur le fait que Windows Loader aurait été scanné avec un antivirus avant mise en ligne, et qu’il serait « garanti sans virus » à condition de le télécharger via un lien spécifique. Dans la réalité, un binaire de ce type reste une cible idéale pour un acteur malveillant : public nombreux, recherche de gratuité, habitude de désactiver les protections, absence totale de support officiel.
Les cas de figure rencontrés dans les parcs IT vont du simple homelab au parc de 50 postes, tous activés via ce chemin :
- machines perso recyclées en labo de test sous Windows 7, activées pour éviter les rappels d’activation
- postes bureautiques dans une petite structure, configurés par un « ami qui s’y connaît » à partir de Windows Loader
- serveurs de test avec Windows Server 2008/2012 R2, montés dans l’urgence pour une démo interne
Une fois cet historique enfoui, les problèmes réapparaissent plus tard, sous une autre forme : migrations impossibles, incompatibilités avec certains agents de sécurité, échecs inexpliqués dans les mises à jour cumulatives. Atelier Duverne a par exemple découvert que son serveur de fichiers principal, théoriquement sous Windows Server correctement licencié, avait en fait été « activé » avec Windows Loader par un prestataire précédent. Lors de la tentative de mise à niveau, l’installateur refusa de continuer, avec un message sibyllin sur la validité de la licence.
Cette réalité se lit très nettement quand on compare le schéma de téléchargement et d’installation d’un binaire sain à celui d’un loader comme celui-ci.
| Étape | Scénario classique (logiciel légitime) | Scénario Windows Loader v2.2.2 |
|---|---|---|
| Source du téléchargement | Site éditeur, store officiel, portail entreprise | Forums, hébergeurs de fichiers, blogs anonymes |
| Intégrité du fichier | Checksum, signature numérique, versioning documenté | Archive compressée, peu ou pas de vérification d’intégrité |
| Interaction avec l’antivirus | Autorisation explicite, exclusion ciblée si nécessaire | Désactivation totale de la protection en temps réel recommandée par les tutos |
| Élévation de privilèges | Installation via MSI ou setup signé | Exécutable inconnu lancé en administrateur |
| Documentation | Guide officiel, KB, support éditeur | Captures d’écran sur des blogs, vidéos non officielles |
Pour quelqu’un qui gère une infra, ce genre de schéma suffit à trancher : même si le binaire ne contient pas, à l’instant T, de code malveillant évident, le processus d’installation sort complètement des pratiques acceptables dans un système en production. C’est d’ailleurs souvent le vrai sujet quand on tombe sur cet outil durant un audit : moins la présence du loader lui-même que tout ce qu’il raconte sur la manière dont les postes ont été gérés jusque-là.
Statut légal de Windows Loader v2.2.2 : ce que disent la licence Microsoft et la pratique
Sur le volet légal, Windows Loader v2.2.2 coche quasiment toutes les cases du logiciel controversé. Les Conditions de licence de Microsoft sont explicites : le contournement des mécanismes d’activation, la falsification des informations de licence ou l’usage de clés non autorisées constituent une violation du contrat. Du point de vue juridique, l’outil opère clairement un contournement de l’activation Windows pour simuler une licence Windows inexistante.
Cela ne signifie pas pour autant que tous les utilisateurs se retrouvent immédiatement poursuivis. Dans les faits, Microsoft a longtemps adopté une politique pragmatique, surtout sur Windows 7 : tolérance relative envers les postes domestiques, focus sur les piratages massifs et les environnements d’entreprise, incitations régulières à migrer vers des versions plus récentes et à régulariser les licences. Certains commentateurs en ont conclu, un peu vite, que l’usage de Windows Loader serait « en pratique encouragé ». C’est une lecture discutable, notamment pour une entreprise.
Dans un environnement pro, trois aspects posent problème :
- la non-conformité contractuelle vis-à-vis de Microsoft, qui peut ressortir lors d’un audit SAM
- les conséquences comptables d’une régularisation en bloc, parfois sous contrainte
- le risque d’image vis-à-vis des clients et partenaires, surtout en cas d’incident de sécurité
Un éditeur qui découvre lors d’un audit que 47 % de ses postes Windows 7 tournent sur un logiciel pirate d’activation ne va pas forcément déclencher une tempête médiatique, mais l’entreprise se retrouve en position de faiblesse : négociation accélérée, régularisation sous délai, investissements non planifiés. Pour un acteur industriel, la situation peut même bloquer la réponse à certains appels d’offres qui exigent une conformité logicielle documentée.
Sur le plan éthique, le débat est plus nuancé. Certains administrateurs avancent que l’usage occasionnel d’un loader sur une machine de test isolée ne représente pas le même enjeu qu’un parc entier de postes de production en fraude. Techniquement, cette nuance existe. Juridiquement, les textes ne distinguent pas les bonnes intentions des autres. Côté Atelier Duverne, par exemple, personne n’avait vraiment « décidé » de pirater Windows ; un prestataire avait juste « activé les postes » sans détailler sa méthode.
Pour visualiser les écarts entre ces situations, un tableau rapide aide à structurer la réflexion.
| Contexte | Usage de Windows Loader | Risque légal | Risque opérationnel |
|---|---|---|---|
| PC personnel hors réseau pro | Activation de Windows 7 pour un usage domestique | Infraction aux CLUF, rarement poursuivie isolément | Risque surtout lié aux binaires vérolés et au support inexistant |
| Homelab d’un admin | Tests ponctuels sur quelques VM Windows 7 | Infraction contractuelle, faible probabilité d’audit ciblé | Peut fausser des tests de migration ou de sécurité |
| TPE/PME avec parc de 20 postes | Activation généralisée via Windows Loader | Non-conformité globale en cas d’audit Microsoft ou partenaire | Difficultés lors des migrations, perte de confiance des partenaires |
| Entreprise de taille moyenne | Serveurs et postes critiques activés illégalement | Risque financier fort en cas de régularisation forcée | Impact sur les plans de continuité et les certifications (ISO, etc.) |
La ligne directrice qui se dégage pour les organisations est relativement simple : la présence de Windows Loader v2.2.2 dans un SI devrait être traitée comme un incident de conformité, à documenter, corriger et prévenir. S’en accommoder au nom d’un pseudo « compromis » pourrait coûter bien plus cher que quelques licences régulières à moyen terme.
Risques de sécurité informatique liés à Windows Loader et aux clones de loaders d’activation
Sur le terrain de la sécurité informatique, Windows Loader appartient à une catégorie ambiguë. À l’origine, le binaire cherche surtout à fonctionner comme un outil d’activation. Mais son mode de diffusion et les privilèges qu’il réclame en font une cible de choix pour les développeurs de malwares. Et là, le distinguo entre « simple contournement d’activation Windows » et cheval de Troie devient vite très flou pour l’utilisateur final.
Les moteurs antivirus le classent fréquemment dans des familles génériques, du type « Trojan.Generic », « HackTool » ou « RiskTool ». Cette classification ne signifie pas automatiquement que chaque copie embarque un ransomware, mais elle traduit une réalité claire : un exécutable inconnu, lancé en administrateur, qui intervient sur la chaîne de démarrage et tente de masquer sa présence porte tous les marqueurs d’un comportement suspect.
Dans de nombreux cas, les variantes distribuées sur des sites douteux ajoutent une charge supplémentaire :
- installation de miners qui profitent des ressources CPU des postes
- ajout de backdoors pour un contrôle à distance
- injection de modules de vol de mots de passe ou de cookies
Les environnements qui tolèrent ce type d’outils ouvrent en pratique une brèche fonctionnelle : les utilisateurs s’habituent à désactiver leur antivirus, les administrateurs minimisent les alertes, et les logs sont encombrés de détections liées au loader, au point de masquer d’autres signaux plus graves. Sur Atelier Duverne, les journaux de l’antivirus central remontaient depuis des mois des alertes répétées sur un même exécutable classé « HackTool ». Personne ne prenait le temps de creuser, jusqu’à ce qu’un incident plus sérieux force une vraie analyse.
Un autre problème se cache dans la persistance. En modifiant la chaîne de démarrage et certaines zones sensibles du système, Windows Loader peut compliquer le travail d’outils de sécurité avancés :
- incompréhension de certains agents EDR qui doivent injecter leur propre code très tôt dans le boot
- fausse impression de compromission profonde alors que l’élément perturbateur est ce loader « historique »
- résistances inattendues lors de tentatives de nettoyage automatisé
Clairement, sur une machine qui héberge déjà des données sensibles, l’équation n’a pas de sens. Le gain financier à court terme, lié à l’absence d’achat de licence, se paye en complexité accrue lors d’un incident. L’équipe sécurité doit alors distinguer ce qui relève du piratage de licence de ce qui relève de l’intrusion malveillante, dans un contexte brouillé par des outils comme Windows Loader.
On peut résumer l’impact global de ces loaders sur la posture de sécurité d’un poste dans un tableau synthétique.
| Aspect sécurité | Effet typique de Windows Loader v2.2.2 | Conséquence possible |
|---|---|---|
| Politique antivirus | Désactivation temporaire demandée par les tutos | Fenêtre d’exposition pendant laquelle d’autres malwares peuvent s’installer |
| Chaîne de boot | Modification pour injection SLIC | Interactions imprévues avec EDR, Secure Boot, outils forensic |
| Provenance du binaire | Sites non officiels, archives non signées | Risque d’ajout de charge malveillante par un tiers |
| Habitudes des utilisateurs | Normalisation de la désactivation des protections | Affaiblissement des réflexes d’hygiène numérique |
| Visibilité SOC / EDR | Alertes répétées classées « HackTool » | Risque de bruit de fond qui masque des signaux plus critiques |
Pour un responsable sécurité, le choix est rapide : tolérer des outils de ce type revient à accepter une zone d’ombre dans le système d’information. Même si le loader utilisé aujourd’hui ne contient pas de code malveillant, le simple fait de maintenir ce mode opératoire valide un modèle dangereux : télécharger, dézipper, désactiver l’antivirus, exécuter en administrateur. Sur le long terme, cette habitude crée plus de problèmes qu’elle n’en résout.
Alternatives légales et stratégies de sortie pour les environnements encore dépendants de Windows Loader
La vraie question pour les équipes techniques n’est pas de débattre du charme nostalgique de Windows Loader sur Windows 7, mais de savoir comment en sortir proprement. En 2025, continuer à investir dans des mécanismes d’activation bricolés sur un système en fin de vie n’a que peu de sens. Il reste pourtant encore beaucoup de parcs mélangés, où quelques postes sous Windows 7 activés via loader cohabitent avec des machines plus récentes.
Une stratégie de sortie raisonnable combine généralement trois volets :
- inventaire des machines concernées et des usages réels
- choix du modèle de licence Windows adapté (OEM, Retail, Volume, abonnements Microsoft 365)
- plan de migration ou de réinstallation pour repartir sur un socle sain
Sur la partie inventaire, des outils comme PowerShell, les agents de supervision ou les solutions de gestion de parc permettent de repérer :
- les postes encore sous Windows 7 ou Windows Server 2008/2012 R2
- les signatures d’activation suspectes (clés génériques, absence de trace KMS, etc.)
- les binaire connus de loaders d’activation sur disque
Une fois la cartographie obtenue, il reste à choisir les voies de régularisation réalistes. Dans certains cas, un simple achat de licences OEM ou Retail pour quelques postes isolés suffit. Dans d’autres, le passage à des licences en volume ou à des offres par utilisateur via Microsoft 365 devient plus pertinent, surtout si une montée vers Windows 10 ou 11 est prévue.
Un tableau récapitulatif aide à positionner les principales options face à la situation d’un parc hérité de Windows Loader.
| Option | Contexte adapté | Avantages | Limites |
|---|---|---|---|
| Achat de licences OEM neuves | Renouvellement de quelques postes physiques | Coût unitaire souvent faible, support constructeur | Lié au matériel, peu flexible, pas adapté aux VM |
| Licences Retail / boîtes | Petites structures avec peu de postes | Transférable d’une machine à l’autre, gestion simple | Gestion manuelle des clés, pas idéal à grande échelle |
| Licences en volume (MAK/KMS) | Entreprises avec parc significatif | Centralisation de l’activation, suivi plus propre | Nécessite une gestion sérieuse des serveurs KMS |
| Abonnements Microsoft 365 | Parcs modernes, multi-appareils par utilisateur | Activation liée aux comptes, mise à jour continue | Modèle récurrent, besoin d’un pilotage plus fin |
| Virtualisation / VDI | Postes vieillissants mais applicatifs à conserver | Centralisation, durcissement plus simple | Investissement initial en infra, licences spécifiques |
Pour Atelier Duverne, la sortie s’est jouée en deux temps. D’abord, régularisation minimale sur quelques postes critiques encore sous Windows 7, le temps de finaliser la migration des applicatifs. Ensuite, bascule planifiée vers un mix de Windows 10/11 sous licences en volume et de quelques VM dédiées aux vieilles applications, hébergées dans un environnement mieux cloisonné. Le point clé : suppression systématique des loaders d’activation, avec réinstallation propre dès que possible.
Une fois les postes régularisés, il reste à éviter une rechute. Cela passe par des règles internes claires :
- interdiction explicite des logiciels pirates d’activation dans la charte informatique
- intégration de la gestion des licences dans les procédures d’onboarding des machines
- contrôle ponctuel des exécutables classés « HackTool » dans les rapports de sécurité
L’expérience montre qu’un parc sorti de ce type de zones grises devient plus simple à superviser, plus prévisible lors des montées de version et, surtout, plus défendable face à un audit externe. En pratique, le thème Windows Loader n’est souvent qu’un symptôme d’un autre problème : l’absence de gouvernance claire sur les licences et la sécurité des postes. Une fois ce problème adressé, le besoin d’un loader disparaît de lui-même.
Windows Loader v2.2.2 est-il légal pour activer Windows 7 dans une entreprise ?
Non. Windows Loader v2.2.2 réalise un contournement explicite des mécanismes d’activation Windows prévus par Microsoft. Son utilisation viole les conditions de licence et place l’entreprise en situation de non-conformité, notamment en cas d’audit SAM ou de contrôle de conformité logicielle. Pour un environnement professionnel, il vaut mieux considérer toute machine activée avec ce type d’outil comme prioritaire pour une régularisation ou une migration.
Pourquoi les antivirus détectent-ils Windows Loader comme une menace alors que certains disent qu’il n’y a pas de virus ?
Les moteurs de sécurité classent Windows Loader comme HackTool, RiskTool ou cheval de Troie, non pas uniquement sur la base d’un code malveillant identifié, mais en raison de son comportement : modification de la chaîne de démarrage, élévation de privilèges, tentative de masquer sa présence, contournement de l’activation Windows. En plus, beaucoup de copies distribuées sur des sites tiers embarquent des charges ajoutées, comme des miners ou des backdoors. Même si un binaire donné ne contient pas de malware, le risque global reste élevé.
Windows Loader est-il encore utile en 2025 alors que Windows 7 n’est plus supporté ?
Sur le plan purement pratique, certains continuent à l’utiliser pour garder en vie des machines Windows 7 ou d’anciens Windows Server sans payer de licences. Mais en 2025, le système n’est plus supporté, ce qui cumule les risques de sécurité et les problèmes de conformité. Pour les postes connectés au réseau d’une entreprise, maintenir un socle non supporté et activé via un outil pirate n’a plus vraiment de justification technique défendable. La bonne approche consiste plutôt à migrer vers des versions supportées et des licences légales.
Comment détecter la présence de Windows Loader dans un parc existant ?
On peut combiner plusieurs approches : repérer les postes encore sous Windows 7 ou Windows Server 2008/2012 R2, analyser les informations d’activation (clés génériques, absence de traces KMS ou MAK dans les inventaires), rechercher les exécutables connus de loaders d’activation sur disque, et examiner les alertes antivirus classées HackTool ou RiskTool. Un script d’inventaire PowerShell couplé aux logs de sécurité donne souvent une première cartographie assez fiable.
Quelle est la meilleure alternative à Windows Loader pour un homelab ou des tests ?
Pour un homelab, le plus propre reste d’utiliser les versions d’évaluation officielles de Windows ou des licences issues de programmes MSDN/Visual Studio, quand c’est possible. Les éditions d’essai de Windows Server, par exemple, couvrent largement la plupart des besoins de test. Autre piste : s’appuyer davantage sur Linux pour les scénarios de labo qui ne nécessitent pas absolument Windows. Même en test, éviter les loaders permet d’obtenir un comportement plus proche de ce que l’on rencontrera en production.
