Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Six campagnes de manipulation de la chaîne d'approvisionnement ont touché npm, PyPI, les modules Go et Packagist entre mars et juillet 2026.
- Aucun d'entre eux n'avait besoin d'un bug dans le code d'une application quelconque, mais simplement d'une étape fiable dans la chaîne de distribution.
- Trois des six sont arrivés et repartis en l'espace de quelques heures, ce qui est plus rapide que la plupart des programmes de scan.
- Le système de détection post-installation a été conçu pour une attaque plus lente que celle à laquelle les équipes sont actuellement confrontées.
Deux des campagnes les plus rapides de cette année montrent à quel point un pirate a besoin de peu de temps. Le 31 mars, deux versions corrompues d’Axios sont restées sur npm pendant environ trois heures avant que quelqu’un ne les retire. La prise de contrôle de Mastra s’est déroulée encore plus rapidement, avec la republication de plus de 140 paquets en environ 88 minutes le 17 juin. Microsoft attribue ces deux incidents à Sapphire Sleet, tandis que Google lie la compromission d’Axios au groupe nord-coréen qu’il appelle désormais Midnight Neptune, anciennement UNC1069. Aucune de ces deux compromissions n’a été stoppée avant que les versions malveillantes n’atteignent les utilisateurs, et dans aucun des deux cas, personne n’a modifié le code source du paquet. L’attaquant a ajouté une seule dépendance au fichier package.json et a laissé npm install faire le reste.
SCA traditionnel axé sur les CVE et SBOM n’ont jamais été conçus pour bloquer l’un ou l’autre, car au moment où cela comptait, il n’y avait rien à comparer. Ces deux fenêtres se sont ouvertes et refermées en moins de temps qu’il n’en faut pour terminer de nombreuses versions nocturnes.
Voilà à quoi ressemble l’année 2026 jusqu’à présent. Pas une seule faille majeure dont tout le monde continue de débattre des mois plus tard, mais une succession ininterrompue de campagnes courtes, rapides et menées avec brio, qui s’attaquent les unes après les autres aux registres publics, tandis que la plupart des systèmes de défense se trouvent encore tout au bout de la chaîne de traitement, attendant de signaler ce qui s’est déjà produit.
Qu'est-ce qui a changé entre 2025 et 2026 ?
Si l'on aligne ces dates, la tendance est on ne peut plus évidente. Six campagnes confirmées ont été menées sur une période de cinq mois, de mars à juillet 2026, dans quatre écosystèmes différents. Cela revient à environ une campagne majeure, confirmée de manière indépendante, par mois, dont plusieurs sont attribuées à des acteurs malveillants identifiés.
Et les données globales sur les menaces indiquent qu’il ne s’agissait pas seulement d’une période particulièrement difficile. Le rapport de Wiz sur les menaces dans le cloud pour le premier semestre 2026 a révélé que le volume d’incidents significatifs signalés aux clients avait augmenté de 60 % par rapport au second semestre 2025, soit le niveau le plus élevé jamais enregistré, les attaques visant la chaîne d’approvisionnement passant d’environ 10 % à 25 % de ces incidents. Wiz recense les incidents liés au cloud plutôt que l’état de santé des registres, ce qui permet d’interpréter ces chiffres comme une confirmation indépendante de la tendance, plutôt que comme un fournisseur confirmant sa propre thèse. Le groupe Threat Intelligence de Google estime avec un haut degré de certitude que la croissance des campagnes à très grande échelle ciblant la chaîne d’approvisionnement open source tout au long de l’année 2025 et au début de l’année 2026 reflète une véritable expansion de cette tactique plutôt qu’une amélioration des capacités de détection ; les chiffres de l’OpenSSF qu’il cite indiquent une hausse de plus de 1 400 % du nombre de paquets open source malveillants identifiés entre 2024 et 2025.
La durée de chaque campagne est l'élément qui mérite le plus d'attention. Mastra a duré environ 88 minutes. Axios a duré environ trois heures. Les cinq versions malveillantes de jscrambler ont été diffusées sur une période à peu près identique. Les autres campagnes ont suivi le chemin inverse, se déroulant discrètement pendant des semaines, ce qui est sans doute pire encore. Les deux extrêmes de cette fourchette posent problème pour les outils conçus pour détecter les menaces selon une cadence nocturne.
Retour à la réalité : Une campagne par mois ne signifie pas pour autant une augmentation proportionnelle du nombre d’attaquants. L’automatisation explique en grande partie ce phénomène, et l’année 2026 en a fourni un exemple flagrant. Le 12 mai, TeamPCP a publié sur GitHub le code source complet du ver Mini Shai-Hulud, et des campagnes dérivées utilisant cette chaîne d’outils ont fait leur apparition en l’espace de quelques semaines. La publication d’un paquet peut être automatisée, le vol d’identifiants peut être automatisé, et l’usurpation d’espace de noms est automatisable depuis des années.
Vous pouvez également en savoir plus sur le « slopsquatting » et les « hallucinations » des packages d'IA dans notre présentation détaillée.
Les six campagnes qui ont défini le modèle
Les six cas ci-dessous ne constituent pas un classement des six incidents les plus fréquents en termes de nombre de paquets. Il s’agit des six incidents qui illustrent le mieux l’éventail des événements survenus cette année, allant des détournements d’identifiants volés (axios, jscrambler) à un ver à propagation autonome, en passant par la réactivation d’un compte inactif, une injection de messages ciblant des évaluateurs d’IA et une prise de contrôle de compte orchestrée par l'ingénierie sociale.
| Campagne | Date | Écosystème des paquets | Qu'est-ce qui a permis que cela fonctionne ? |
| détournement d'Axios | 31 mars | npm | L'ordinateur du responsable principal de la maintenance a été compromis par une attaque d'ingénierie sociale, puis deux versions corrompues ont été directement publiées sur npm, où elles sont restées en ligne pendant environ trois heures. Cet incident a été attribué à « Sapphire Sleet » par Microsoft et à « Midnight Neptune » par Google. |
| Mini Shai-Hulud | À partir du 29 avril | npm | Ver auto-propagateur qui récupérait les identifiants npm et CI, puis se réintégrait dans tous les paquets que ses victimes pouvaient publier. Attribué à TeamPCP. |
| Hadès | 7 et 8 juin | PyPI | 19 paquets ont été expédiés, contenant 37 « wheels » malveillants dotés de hooks de démarrage au format .pth, avec du texte d'injection d'invite destiné à la vérification par un modèle de langage de grande envergure (LLM). Ils font partie de la gamme Miasma, elle-même dérivée de Mini Shai-Hulud. |
| Reprise de Mastra | 17 juin | npm | Compte de contributeur inactif, inactif depuis février 2025, dont les droits d'accès n'ont jamais été révoqués, utilisé pour republier plus de 140 paquets contenant une dépendance injectée. Il s'agit du même acteur que dans le cas d'axios. |
| jscrambler | 11 juillet | npm | Des identifiants d'éditeur volés ont été utilisés pour diffuser cinq versions contenant un programme de vol d'informations multiplateforme, les trois premières via un hook de préinstallation. |
| PolinRider | À partir de mars | npm, Go, Packagist | Des comptes de responsables de maintenance ont été piratés à l'aide d'outils de développement malveillants et de procédures de récupération de compte, puis utilisés pour implanter des chargeurs obfusqués dans 108 paquets et extensions. Ces incidents ont été recensés début juillet et sont liés au cluster « Contagious Interview ». |
Si l’on passe ces six cas en revue, on constate qu’ils ont tous un point commun. Aucun d’entre eux n’a nécessité l’exploitation d’une faille dans le code de la victime. Chacun a exploité une étape de confiance située quelque part entre le clavier d’un responsable de maintenance et votre commande d’installation, et dans quatre de ces six cas, cette étape correspondait à un compte de responsable de maintenance légitime.
Le point commun entre Axios et Mastra n'est pas une simple coïncidence de style. Microsoft a confié les deux campagnes au même créateur; ainsi, au moins deux des six faisaient partie d’un même groupe affinant son approche d’une campagne à l’autre, plutôt que de deux équipes ayant abouti à la même idée. Hades et Mini Shai-Hulud partagent également un arbre généalogique. Six campagnes, donc, mais qui s’apparentent davantage à quatre groupes distincts, ce qu’il convient de préciser avant que quiconque n’interprète ce décompte comme représentant six groupes indépendants.
Hades est celui qui mérite qu’on s’y attarde un instant. Ses paquets contenaient une injection d’invite en texte clair destinée à convaincre un analyseur basé sur un modèle de langage (LLM) de les classer comme sûrs, ce que les chercheurs ont décrit comme une technique de contournement novatrice ; cette stratégie ne fonctionne que si les attaquants partent du principe que des outils d’IA se trouvent désormais entre le paquet et l’ingénieur. D’ici mi-2026, ce scénario n’est pas du tout invraisemblable. L’affaire Maven Central, survenue en décembre, avait utilisé un « bruit » similaire pour contourner l’analyse par apprentissage automatique ; cette technique mûrissait donc discrètement depuis des mois. Hades exécutait également un moniteur de jetons qui menaçait de mener des actions destructrices si les jetons GitHub volés étaient révoqués, ce qui modifie discrètement l’ordre des opérations pour quiconque tente de nettoyer le système.
PolinRider est celui dont il faut se méfier, pour une raison différente. Il ne s’agissait pas d’un squat opportuniste de noms de domaine abandonnés, et la voie d’accès signalée est plus étrange qu’un simple vol d’identifiants. Les chercheurs affirment que les identifiants GitHub volés n’étaient pas du tout le vecteur d’attaque. Les victimes ont d’abord été compromises via une extension VS Code ou un paquet npm malveillant, la prise de contrôle du responsable du projet s’effectuant ensuite par le biais de domaines expirés ou d’autres voies de récupération de compte, le tout dissimulé sous le techniques d’ingénierie sociale qui fait la réputation de l’équipe de Contagious Interview. Une bonne hygiène de publication ne fait pas disparaître ce risque : le maillon faible réside dans les outils utilisés par le responsable de maintenance et dans la procédure de récupération de compte, plutôt que dans le processus de publication.
Deux autres campagnes de 2026 sont évoquées plus loin dans cet article. TrapDoor a implanté 34 paquets malveillants sur npm, PyPI et Crates.io, tandis que Laravel-Lang a vu plus de 700 versions corrompues par la réécriture de balises Git. TeamPCP est un cas à part. Il ne fait pas l’objet d’une rubrique distincte, car la rubrique « Mini Shai-Hulud » correspond déjà à TeamPCP. Cette opération de plus grande envergure, que Google désigne sous le nom d’UNC6780, s’est déroulée de février à mai et a enchaîné des compromissions de CI/CD visant des outils de sécurité , notamment Trivy, Checkmarx et ses images Docker KICS, ainsi que LiteLLM, en une longue campagne de collecte d’identifiants. Cela dépasse le cadre d’une ligne de tableau – mais le mécanisme est le même.
La surface d'attaque s'est déplacée vers la phase d'installation
Le fil conducteur de toute l'année 2026, c'est le timing.
Les attaquants ont exploité la même faille dans npm, PyPI et Cargo sous trois angles différents, et TrapDoor en est l’exemple le plus parlant, car une seule campagne a utilisé ces trois méthodes. Un hook post-installation sur npm, une exécution au moment de l’importation sur PyPI, et un script build.rs qui se déclenche lors de la compilation Cargo sur Crates.io. Des déclencheurs différents, mais un même principe. Le code s’exécute lors de l’acquisition du paquet, et non lors de son utilisation. Le volet Go de PolinRider fonctionne encore différemment, puisque la charge utile se trouve dans les fichiers de configuration des outils de compilation et les tâches de VS Code plutôt que dans un hook d’installation ; il se déclenche donc lorsque l’environnement de développement d’un développeur ouvre le projet, et non lors de la commande `go get`. Même abus de confiance, mais à un stade différent du pipeline.
Les outils standard partent du principe qu’il existe un délai entre l’apparition d’une dépendance et son exécution, suffisamment long pour qu’une analyse puisse détecter un problème au préalable. L’exécution lors de l’installation supprime ce délai pour tout ce qui se contente d’inspecter les artefacts après la résolution des dépendances.
Imaginez une équipe d’ingénieurs de 40 personnes disposant d’un pipeline raisonnablement abouti. Dependabot ouvre des PR, un outil SCA analyse le fichier de verrouillage, l’intégration continue (CI) bloque tout élément de gravité élevée, et une SBOM est générée au moment de la compilation. Cette configuration gère bien les dépendances dont la vulnérabilité est connue. Elle s’avère en revanche bien moins efficace face à une version publiée il y a une heure, qui ressemble à une simple mise à jour mineure, s’exécute lors de l’installation et est retirée avant le déjeuner. Aucun avis de sécurité ne correspondait à un élément de cette chaîne, et dans les cas d’axios et de Mastra, la charge utile se trouvait un niveau plus bas, à l’intérieur d’une dépendance que le scanner n’avait aucune raison d’examiner de plus près.
Attention : Le « pinning » précis est plus efficace qu’on ne le pense, mais moins qu’on ne l’espère. Tous ceux qui ont utilisé un axios « propre » et qui n’ont pas effectué de nouvelle installation pendant cette fenêtre de trois heures s’en sont bien sortis. Ce que le « pinning » ne vous dira pas, c’est si la version vers laquelle vous passez délibérément est fiable, et il ne sert à rien lorsqu’une plage vague sur une dépendance transitive se charge de la résolution à votre place. C’est exactement ce qui s’est produit avec Mastra, puisque la dépendance « easy-day-js » injectée était déclarée comme une plage « caret » et que npm a allègrement effectué la mise à jour vers la version de correctif « armed ». Le « pinning » suppose également que l’artefact associé à une version ne peut pas changer, ce que Laravel-Lang a réfuté en réécrivant des balises historiques pour qu’elles pointent vers un nouveau commit.
Le filtrage des paquets avant qu’ils n’atteignent la machine d’un développeur ou un agent de compilation est l’un des rares maillons de la chaîne où le code au moment de l’installation peut être bloqué, plutôt que d’être signalé a posteriori. C’est là que réside la lacune que SecureChain for OSS a été conçu pour combler, et c’est également la raison pour laquelle il intervient au niveau du registre plutôt que d’ajouter un scanner supplémentaire à la fin du pipeline.
Pourquoi votre scanner est toujours en retard
L'analyse traditionnelle de la composition logicielle axée sur la lutte contre la cybercriminalité (CVE) est efficace pour répondre à une question précise : quels composants présentant des vulnérabilités connues ont été intégrés à cette version ? Elle est vraiment performante dans ce domaine, et mérite d'être conservée.
En soi, cela ne répond toutefois pas à une autre question : cet artefact correspond-il, à l'heure actuelle, à ce que son responsable a publié ?
Il s'agit davantage d'un problème lié aux données que d'un problème lié au produit. L'analyse SCA axée sur les vulnérabilités compare votre inventaire de dépendances aux données des avis de sécurité, et un avis n'existe qu'une fois que quelqu'un a découvert le paquet malveillant, l'a signalé et a obtenu sa publication. La détection est souvent rapide. Socket a signalé la version malveillante de jscrambler six minutes après sa publication, et les paquets TrapDoor ont été détectés en moins de six minutes en moyenne entre leur publication et leur détection. La consultation de l’avis de sécurité par votre scanner constitue la partie la plus lente du processus, et bon nombre de ces incidents ne donnent jamais lieu à un CVE, ce qui explique également pourquoi aucun d’entre eux n’apparaîtra jamais dans le catalogue des vulnérabilités exploitées connues de la CISA. Les flux d’avis de sécurité constituent, par nature, un registre de ce qui a déjà été découvert.
Bon à savoir : Plusieurs campagnes « 2026 » ont publié des versions malveillantes qui ressemblaient à de simples mises à jour de version, sans commit, pull request ni balise correspondants. jscrambler 8.14.0 en est l’exemple le plus flagrant, puisque les chercheurs n’ont trouvé aucun commit, aucune balise ni aucune pull request le concernant dans le dépôt GitHub du projet, où la dernière balise était toujours 8.13.0. Les outils de mise à jour classiques ne vérifient pas si un artefact correspond à une modification du code source. Ils détectent un nouveau numéro de version, ouvrent une pull request, et certaines équipes la fusionnent automatiquement. Une mise à jour de version et une modification vérifiée ne sont pas la même chose.
Ce que laissent présager les chiffres relatifs à l'écosystème
Jusqu'en 2024 et pendant la majeure partie de l'année 2025, npm a monopolisé l'attention, grâce à son nombre d'utilisateurs et à ses scripts de cycle de vie qui s'exécutent automatiquement lors de l'installation. Cette période d'attention exclusive est désormais révolue.
TrapDoor a touché trois écosystèmes au cours de la même semaine en mai, avec 34 paquets malveillants et plus de 384 versions sur npm, PyPI et Crates.io. Il s’agissait d’outils factices plutôt que piratés, dont les noms étaient conçus pour ressembler à des utilitaires qu’un développeur spécialisé dans la cryptographie ou l’IA installerait sans y réfléchir à deux fois, et chaque registre disposait de son propre chemin d’exécution. Le malware a également déposé des fichiers .cursorrules et CLAUDE.md pour manipuler les assistants de codage basés sur l’IA, ce qui donne un bon aperçu de la direction que prendra ce type d’attaque.
Packagist a lui aussi connu un mois de mai difficile. Les pirates ont modifié toutes les balises Git de quatre dépôts de localisation Laravel-Lang en l'espace d'environ 90 minutes, les 22 et 23 mai, et plus de 700 versions historiques ont fini par pointer vers un commit malveillant que l’autochargeur de Composer a ensuite exécuté à chaque requête. L’intrusion a été rendue possible par la fuite d’un jeton GitHub, et le code source du projet n’a jamais été altéré. Par ailleurs, une campagne portant sur huit paquets a dissimulé sa charge utile dans le fichier package.json plutôt que dans composer.json, ce qui la plaçait exactement là où une revue axée sur PHP était le moins susceptible de la repérer.
Vous pouvez également découvrir les bonnes pratiques pour protéger votre environnement PHP dans notre guide complet sur la sécurité de Laravel.
Et en décembre 2025, juste avant la période couverte par cet article, un faux site « Jackson » issu d’un typosquatting a fait son apparition sur Maven Central, embarquant une balise Cobalt Strike. L’astuce consistait en un échange de préfixe : « org.fasterxml » à la place de « com.fasterxml » utilisé par la véritable bibliothèque, ce que la convention de domaine inversé de Java ne permet pas de détecter. Aikido, qui l’a découvert, l’a qualifié de premier logiciel malveillant sophistiqué que son équipe ait détecté sur Maven Central ; il faut donc considérer cela comme une première pour ces chercheurs plutôt que pour l’écosystème dans son ensemble. Le retrait a été rapide, du moins, environ 90 minutes après le signalement.
Il faut y voir un changement dans la cible des campagnes de sensibilisation plutôt qu’un simple « avant » et « après », car des paquets malveillants avaient déjà été détectés dans la plupart de ces registres auparavant. Pour une entreprise polyglotte, la conclusion pratique est que les défenses par écosystème ne suffisent plus à assurer une couverture réelle. Des contrôles rigoureux sur npm, des pratiques laxistes sur PyPI et une absence totale de mesures pour Go ou Rust reviennent à avoir une porte d’entrée verrouillée et plusieurs entrées latérales ouvertes ; or, les données de cette année indiquent que les attaquants tentent déjà de s’y introduire.
Que faire pour y remédier ?
Tout cela ne nécessite aucune refonte de l'architecture. Tout cela est réalisable au cours de ce trimestre.
Si vous disposez d'un écosystème principal
Commencez par combler cette faille au moment de l’installation. Définissez `ignore-scripts=true` dans le fichier `.npmrc` partout où votre processus de compilation le permet, et acheminez les installations via une couche de registre qui filtre les paquets avant leur résolution. Ne considérez toutefois pas le blocage des scripts comme la solution miracle. Deux des cinq versions malveillantes de jscrambler ont déplacé le dropper hors du hook de pré-installation pour l’intégrer dans le code principal du paquet et dans l’interface CLI, où l’option `–ignore-scripts` n’a absolument aucun effet.
Si vous êtes polyglotte
Identifiez les écosystèmes qui ne disposent d'aucun contrôle avant d'approfondir ceux qui en possèdent déjà. Dans ce modèle de menace, les lacunes de couverture priment sur les lacunes de profondeur. TrapDoor et PolinRider ont tous deux démontré qu'un seul écosystème non contrôlé suffit à réduire à néant le travail effectué partout ailleurs.
Si vous comptez sur les mises à jour automatiques des dépendances
Prévoir un délai avant la mise en ligne des nouvelles versions. Les recommandations d’Unit 42 en matière d’atténuation suggèrent de bloquer toute version publiée au cours des dernières 24 à 72 heures, au motif que la plupart des paquets malveillants sont identifiés et supprimés pendant ce laps de temps, et Wiz adopte une approche similaire avec un délai de 24 heures. Une courte mise en quarantaine permet de neutraliser une grande partie de ces attaques, au prix d'un léger retard dans l'application des correctifs.
Il vaut mieux déplacer un contrôle en amont plutôt que d'en ajouter un autre à la fin. Deux éléments sont ici plus importants que tout le reste : intercepter un paquet avant qu'il ne soit résolu, et vérifier que l'artefact reçu correspond bien à la source et à la version de compilation dont il est censé provenir.
Il vaut la peine d'activer la provenance, à une condition près. Mastra générait une provenance lors des publications sur CI, mais ne l'exigeait pas ; ainsi, un jeton volé pouvait toujours publier sans attestations, tandis que la vague de Mini Shai-Hulud sur TanStack a produit des paquets dotés d'une provenance SLSA valide, car le pipeline lui-même avait été corrompu. Exiger des attestations aurait empêché le premier cas, mais pas le second.
L'ampleur du problème varie également selon les écosystèmes. Le piratage de comptes Go et les hooks de démarrage PyPI constituent des problèmes distincts nécessitant des solutions différentes ; par conséquent, tout mécanisme de contrôle digne de ce nom doit tenir compte de la manière dont chaque écosystème exécute réellement le code.
Ce que cela signifie pour vous
Il n’y a rien d’exotique là-dedans. L’opération « 2026 » n’a pas inventé une nouvelle catégorie de vulnérabilité. Elle a simplement déplacé le champ de bataille vers un endroit que la plupart des équipes ne surveillaient pas : le moment où un paquet est résolu et exécuté, plutôt que celui où quelqu’un finit par l’analyser. Toutes les campagnes figurant sur cette liste, qu’il s’agisse d’un détournement npm de trois heures ou d’un module Go accessible via un compte de mainteneur piraté, ont fonctionné parce que la confiance avait été accordée avant qu’un quelconque mécanisme de contrôle n’ait eu le temps d’intervenir, que ce soit lors de la résolution, de l’installation, de la compilation ou au moment où un éditeur a ouvert le projet.
La vraie question n’est donc pas de savoir s’il faut conserver la détection post-installation. Il faut la conserver. La question est de savoir si la prévention peut intervenir plus tôt, afin qu’une analyse lancée après que la charge utile a déjà mis la main sur les secrets de votre infrastructure ne soit pas la première à vous alerter. SecureChain pour les logiciels libres est destiné aux équipes qui souhaitent bénéficier de cette fonctionnalité sans avoir à la développer elles-mêmes.
FAQ
Qu'est-ce qu'une attaque visant la chaîne d'approvisionnement logicielle ?
Une attaque qui compromet un logiciel en s'attaquant à une dépendance, un système de compilation, un référentiel ou un canal de distribution de confiance, plutôt qu'en ciblant directement votre application. Les campagnes de 2026 ont très majoritairement ciblé les registres publics de paquets et les comptes qui y publient des paquets.
Combien d'attaques visant la chaîne d'approvisionnement logicielle ont eu lieu en 2026 ?
Il n'existe pas de chiffre officiel global. Cet article passe en revue six campagnes majeures confirmées entre mars et juillet 2026, et plusieurs autres se situent juste en dehors de cette période, notamment TrapDoor, Laravel-Lang et l'opération TeamPCP au sens large.
Une SBOM permet-elle de prévenir les attaques visant la chaîne d'approvisionnement ?
Non. Une SBOM répertorie les éléments qui composent une version, ce qui est utile en cas d'incident ou d'audit. Elle ne garantit pas qu'un artefact répertorié soit bien celui publié par son responsable, et elle n'empêche pas l'exécution du code lors de l'acquisition des dépendances.
Quels écosystèmes de logiciels ont été les plus durement touchés ?
npm a été le théâtre de la plupart des incidents les plus médiatisés de 2026, tandis que PyPI, les modules Go, Crates.io et Packagist ont tous fait l'objet de campagnes ciblant plusieurs paquets d'ici le milieu de l'année. Maven Central a quant à lui connu son heure de gloire juste avant le début de l'année.
