- La dérive des abonnements correspond à une augmentation non approuvée du nombre de licences logicielles entre deux renouvellements ; il n'y a en effet aucun moment précis où le total cumulé est comparé aux besoins réels.
- Selon ses résultats du troisième trimestre de l'exercice 2026 (le dernier trimestre publié), Synopsys tire désormais environ 60 % de son chiffre d'affaires lié aux produits de licences à durée déterminée, de type abonnement, contre 40 % provenant de paiements initiaux.
- Les familles de produits modulaires sont celles qui présentent le risque de dérive le plus élevé – TestMAX de Synopsys (DFT, ATPG, Diagnosis, Manager, Advisor, ALE) et Calibre de Siemens EDA (nmDRC, nmLVS, PERC, Auto-Waivers, SONR, Fab Insights) – tandis que les outils à cœur unique, tels que Design Compiler, s'adaptent au rythme de mise en production plutôt que de subir une dérive.
Lorsqu'une équipe de conception de semi-conducteurs demande un module TestMAX DFT supplémentaire pour respecter une échéance de « tape-out », cette demande semble mineure et est approuvée en quelques minutes : il s'agit d'une simple ligne dans le portefeuille de logiciels de Synopsys. Une fois la phase terminée, le module reste provisionné et personne n'est spécifiquement chargé de le libérer. Multipliez ce schéma par une poignée de pools de licences partagées desservant plusieurs milliers d’ingénieurs, et une organisation de conception peut se retrouver avec deux douzaines de postes flottants en plus en un an, que personne n’a approuvés individuellement et que personne n’a examinés collectivement – une accumulation qui apparaît sur la facture de renouvellement.
Lorsqu’une équipe de conception de semi-conducteurs demande un module TestMAX DFT supplémentaire pour respecter une échéance de tape-out, la demande semble mineure et est approuvée en quelques minutes – il s’agit d’un simple poste dans le portefeuille de logiciels de Synopsys. Une fois la phase terminée, le module reste provisionné et personne n’est spécifiquement chargé de le libérer. Multipliez ce schéma par une poignée de pools de licences partagées desservant plusieurs milliers d'ingénieurs, et une organisation de conception peut se retrouver avec deux douzaines de licences flottantes en plus en un an, que personne n'a approuvées individuellement et que personne n'a examinées collectivement – une accumulation qui apparaît sur la facture de renouvellement.
La « dérive des abonnements » désigne l'augmentation progressive et non approuvée du nombre de licences d'un logiciel entre deux renouvellements. Une licence ajoutée par-ci, une autre par-là, et personne ne procède à une réévaluation avant que la période d'abonnement ou de maintenance n'arrive à échéance. Chaque modification est validée individuellement. Personne ne vérifie le total sur douze mois. Le nombre de licences évolue tout au long de l'année. Ce n'est qu'à la réception de la facture de renouvellement que l'on constate pour la première fois le total.
Dans le secteur de la conception de semi-conducteurs, ce phénomène se manifeste le plus rapidement au sein des familles d’outils présentant deux points communs : elles sont généralement commercialisées sous forme d’abonnements renouvelables – Synopsys, par exemple, tire désormais environ 60 % de son chiffre d’affaires lié aux produits de licences à durée déterminée, de type abonnement, contre 40 % de ventes ponctuelles, selon ses derniers résultats trimestriels – et elles sont divisées en de nombreux modules faisant l’objet de licences distinctes, plutôt qu’en un seul produit global.
La suite TestMAX de Synopsys dédiée à la conception pour le test (DFT) – qui comprend des modules DFT, ATPG, de diagnostic et plusieurs autres produits complémentaires – est un environnement où l’on perd beaucoup plus facilement de vue ce qui reste à faire que Design Compiler, l’outil de synthèse monocœur que presque toutes les équipes de conception numérique utilisent quotidiennement. L’ajout d’un module TestMAX supplémentaire pour une phase de projet constitue à chaque fois une décision mineure et justifiable. Le désinstaller une fois cette phase terminée n’incombe à personne en particulier.
Dans une entreprise de conception dont les pools partagés sont utilisés par plusieurs milliers d’ingénieurs, deux licences supplémentaires par mois peuvent sembler insignifiantes. Mais si l’on additionne ces chiffres sur une année, le pool s’est enrichi de deux douzaines de licences que personne n’a approuvées individuellement, et ce calcul s’opère discrètement en arrière-plan dans presque tous les environnements de conception multi-sites.
Un pool de licences flottant n'enfreint aucune règle
À l'approche d'une date limite de « tape-out », un module de testabilité précoce est mis à disposition pour une phase du projet, en plus de l'outil DFT de base que l'équipe utilise déjà en continu. Le module permet de respecter la date limite, la phase se termine, et la licence reste en vigueur – personne n'est chargé de la libérer. Un parc de licences « design-for-test » élargi il y a deux ans pour un programme n'est jamais réduit. Chaque étape est modeste, documentée et justifiable en soi.
Ce qui manque, c'est une vue d'ensemble sur l'ensemble des étapes. Dans la plupart des processus, rien ne permet de vérifier si les ajouts de cette année, pris dans leur ensemble, ont toujours du sens par rapport à la base de référence de l'année dernière – sans parler de savoir si un module complémentaire donné est encore utilisé. Le dossier indique ce qui a été approuvé. Il ne montre pas ce qui s'est accumulé, ni ce qui a discrètement cessé d'être utilisé une fois que la phase qui le justifiait a pris fin.
Pour une entreprise de conception utilisant des licences EDA sur plusieurs sites – souvent plusieurs milliers d’ingénieurs partageant une poignée de pools communs pour la synthèse, le DFT et la disposition –, cet écart s’aggrave rapidement. Une équipe de conception d’un site donné peut demander un module DFT supplémentaire sans savoir ce que deux autres sites ont déjà ajouté au cours du même trimestre, ni si l’un ou l’autre de ces sites utilise encore le module de l’année dernière.
Pourquoi le rapport habituel ne le met pas en évidence
La plupart des rapports sur les licences indiquent ce qui a été activé, et non ce qui a été réellement utilisé. Cette distinction est importante : une activation confirme qu’une licence a été réservée. Elle ne confirme pas pour autant que quelqu’un a travaillé avec l’outil pendant l’heure, la journée ou le trimestre qui a suivi.
La solution la plus courante dans le domaine de la gestion des licences consiste à mettre en place une règle de libération automatique: libérer automatiquement un poste dès lors qu’il est resté inactif pendant un délai défini après avoir été attribué. Cela permet de traiter les cas simples, comme un poste laissé ouvert toute la nuit sans aucune activité. Cette méthode se contente toutefois de déduire l’activité à partir du temps d’attribution, sans la mesurer réellement.
La dérive des droits survit facilement à cette lacune. Une licence ajoutée en mars et rarement utilisée depuis apparaît toujours comme une licence normale et en cours d'utilisation dans tout rapport établi uniquement à partir des journaux de retrait et des compteurs d'inactivité. Le chiffre semble satisfaisant. Personne n'a examiné l'utilisation qui se cache derrière.
Les éléments à vérifier avant votre prochain renouvellement
| Signe | Ce que cela signifie généralement |
|---|---|
| Le parc de licences de synthèse, de DFT ou de conception s'est agrandi au fil de plusieurs cycles de renouvellement sans que personne n'en approuve le montant total. | Les ajouts ont été validés un par un ; le montant total n'a jamais été examiné. |
| Les rapports sur les délais d'inactivité indiquent un bon taux d'utilisation, mais personne ne peut dire qui exécute réellement des tâches sur des postes spécifiques. | Une vue « caisse + minuteur » ne correspond pas à une utilisation effective : le rapport répond à une mauvaise question. |
| Un renouvellement s'adapte à « l'utilisation actuelle » sans que personne ne définisse au préalable de nouvelle base de référence. | Fuite liée au renouvellement : la dérive de cette année devient le seuil minimal de l'année prochaine |
| Les équipes des sites ou des programmes demandent des places supplémentaires sans savoir combien d'autres sites en ont déjà ajouté | La surallocation s'accumule localement, de manière invisible |
Deux façons de combler l'écart
La plupart des solutions de cette catégorie résolvent le premier problème de la même manière. C'est dans la suite des événements que les approches divergent – et que le phénomène de « dérive des abonnements » se manifeste plus précisément.
L’approche habituelle s’articule autour du journal du serveur de licences : disponibilité en temps réel indiquant qui occupe actuellement une licence, suivi des refus pour identifier qui a été refusé et à quel moment, répartition des coûts par service ou par projet, et une règle de récupération automatisée qui libère une licence dès qu’elle reste inactive au-delà d’un délai défini. Certaines plateformes de cette catégorie ajoutent également une couche d’optimisation des abonnements pour la réaffectation des licences cloud, bien qu’il s’agisse d’un mécanisme distinct de la récupération des licences EDA.
Tout cela correspond à des capacités réelles et permet de détecter de véritables gaspillages : une licence que personne n’a pensé à libérer, un schéma de refus qui justifie (ou non) l’achat de capacités supplémentaires, un site qui paie discrètement des licences que personne n’utilise. Rien de tout cela ne vous indique si une licence actuellement occupée est réellement utilisée : tout repose toujours sur les mêmes données de connexion et de temps d’inactivité. Un poste de synthèse utilisé pendant deux minutes toutes les vingt, juste assez souvent pour réinitialiser le minuteur d’inactivité, est considéré comme actif en permanence, quel que soit le nombre de modules superposés à ce même journal.
| Questions à se poser avant le renouvellement | L'approche habituelle | Open iT (Niveau 1 + Niveau 2) |
|---|---|---|
| Ce siège est-il actuellement occupé, et par qui ? | Oui | Oui |
| Est-ce que quelqu'un s'est vu refuser l'accès, et quand ? | Oui – suivi des refus | Oui – Rapports de refus de niveau 1 |
| À quel site ou à quelle unité opérationnelle ce coût est-il imputé ? | Oui | Oui |
| Ce siège est-il resté inoccupé assez longtemps pour se libérer automatiquement ? | Oui, par rapport à un délai d'inactivité fixe | Oui, en fonction de l'inactivité mesurée plutôt que du temps écoulé uniquement |
| La personne qui occupe ce siège est-elle réellement en train d'y travailler en ce moment ? | Non – déduit à partir de la vérification et de la fréquence d'horloge au repos, non mesuré | Oui – activité du clavier, de la souris, du processeur et des périphériques d'E/S mesurée au niveau du terminal, via le rapport « Work Ratio » |
| Les ajouts de cette année – approuvés un par un, site par site – ont-ils donné lieu à quelque chose que personne n'avait examiné avant le renouvellement ? | Non – chaque rapport est en temps réel ou spécifique à chaque site ; aucune donnée n'est agrégée par rapport à la base de référence de l'année dernière. | Oui – L'équipe de mise en œuvre d'Open iT valide le chiffre de dérive avec le client avant le renouvellement, et non site par site de manière isolée. |
C'est cette dernière ligne qui constitue le point de divergence. La disponibilité en temps réel, le suivi des refus, la répartition des coûts et la récupération des postes inactifs répondent tous à des questions concernant un seul poste à un moment donné. Aucun d’entre eux, pris isolément, ne répond à la question que pose un renouvellement : le total cumulé de cette année, constitué de quelques postes ajoutés petit à petit sur chaque site, correspond-il toujours à ce que le parc informatique utilise réellement ? C’est une question différente de « ce poste est-il inactif en ce moment même ? », et un outil conçu pour répondre à la première ne répond pas à la seconde.
À 90 jours d’un renouvellement comme celui-ci, la vraie question n’est pas de savoir si la plateforme dispose d’un nombre suffisant de rapports, mais si l’un d’entre eux apporte une réponse à la question qui compte. Une longue liste de catégories de rapports ne permet pas de contourner ce travail : elle ne fait que déplacer la question de « disposons-nous des données ? » à « quel rapport les contient ? ».
La solution est simple : mesurez la part du temps de connexion effectivement consacrée à travailler dans l'outil, par poste et par application, puis examinez ces chiffres avec le client avant la discussion sur le renouvellement, et non après.
Même sans intervenir directement sur chaque machine, les données de base relatives aux emprunts et aux refus figurant dans les journaux du serveur de licences permettent déjà de cerner la nature du problème : un parc qui s’est agrandi au fil de plusieurs cycles de renouvellement, des schémas de refus qui justifient ou non l’achat de licences supplémentaires, et des sessions restées ouvertes bien après la fin du travail. C’est une réponse concrète et utile à la question « ce parc a-t-il été examiné dans son ensemble ? », mais elle ne permet pas de lever une ambiguïté spécifique : une licence utilisée pendant deux minutes toutes les vingt minutes apparaît comme étant active en continu aux yeux d’un compteur, tout comme une licence qui a été ouverte une seule fois et n’a jamais été fermée. Seule la mesure de ce qui se passe réellement sur la machine permet de distinguer ces deux cas.
C'est précisément ce que permet la mesure directe de l'activité (clavier, souris, processeur, E/S) : elle indique si un module provisionné était réellement utilisé avant le renouvellement, et non après. Cette distinction revêt une importance capitale précisément pour les familles de produits modulaires dont traite cet article : TestMAX de Synopsys se divise en DFT, ATPG, Diagnosis, Manager, Advisor et ALE, tandis que Calibre de Siemens EDA se décline en nmDRC, nmLVS, PERC, Auto-Waivers, SONR et Fab Insights – chacun constituant un produit sous licence distinct qu’une équipe peut provisionner pour une phase de projet sans jamais y revenir. Design Compiler, TestMAX, IC Compiler, Calibre, MATLAB et LabVIEW sont des outils pour lesquels cette comparaison s’applique déjà aujourd’hui.
Les données ne prennent tout leur sens que lorsque quelqu'un peut s'en servir sans avoir à attendre qu'un spécialiste interprète le rapport.
Questions fréquemment posées
Qu'est-ce que la « dérive des abonnements » dans la gestion des licences logicielles ?
La « dérive des abonnements » désigne l'augmentation progressive et non contrôlée du parc de droits d'utilisation d'un logiciel : des postes, des licences ou des capacités fonctionnelles supplémentaires ajoutés petit à petit au fil du temps, sans qu'à aucun moment le total cumulé ne soit comparé aux besoins réels.
En quoi la dérive d'abonnement diffère-t-elle d'un achat excédentaire ponctuel ?
Un achat excédentaire ponctuel est une décision isolée qui peut être réexaminée et annulée. La dérive, quant à elle, ne résulte pas d’une décision unique. C’est la somme de nombreux ajouts, raisonnables pris individuellement, dont personne n’avait fait le bilan avant le renouvellement.
Comment détecter une dérive des droits avant le renouvellement ?
En comparant régulièrement le parc total de droits à l'utilisation réelle mesurée au niveau des terminaux, et pas seulement lors du renouvellement, et en disposant d'une vue d'ensemble de l'ensemble du parc plutôt que d'un rapport par site ou par gestionnaire de licences.
Le prochain renouvellement aura lieu de toute façon. La seule vraie question est de savoir s'il s'accompagnera d'un montant que votre équipe pourra justifier, ou d'un montant que vous découvrirez tous les deux pour la première fois.
