Le système de tickets ServiceNow : fonctionnement et coût

Ce qu'est réellement un système de tickets ServiceNow

Commençons par le bas. La base explique tout ce qui se trouve au-dessus.

Chaque ticket dans ServiceNow vit dans une table qui étend un unique parent. La documentation même de l'entreprise est directe à ce sujet : la table Task « est une classe de base qui fournit des champs pour les applications ITSM principales comme Incident, Problem et Change Management. Toutes les applications qui étendent la table Task partagent ces champs en commun. »

On ne peut pas écrire directement dans task. Si l'on essaie, un Task Interceptor arrête l'opération et impose de choisir d'abord une table enfant. Le champ sys_class_name enregistre ensuite quel enfant a été choisi. Pour toujours.

Voici toute la famille avec les noms exacts de table, car le nom de la table détermine le comportement :

Les préfixes ne sont pas non plus codés en dur. Ils figurent comme des lignes dans la table sys_number sous System Definition, et n'importe quel administrateur peut les modifier, selon la documentation ServiceNow sur la numérotation des enregistrements. En venant d'un outil plat comme Zendesk, c'est la première vraie différence que l'on ressent : le type d'enregistrement est ici une décision de schéma, pas une liste déroulante sur un formulaire.

Le bénéfice de toute cette héritage est réel, et il mérite d'être reconnu avant que je commence à pointer les failles. Approbations, règles d'assignation, SLA, moniteurs d'inactivité et flux fonctionnent tous sur tout ce qui étend task, donc on les construit une seule fois. C'est la partie qu'un outil de help desk plus petit ne peut pas égaler, et c'est ce qui distingue une plateforme d'un système de tickets automatisé. Les utilisateurs le remarquent aussi.

"Keeping requests, incidents, and changes connected is the core of this platform, which I really appreciate. Plus, finding related knowledge without leaving the ticket open. And lastly, bringing different IT tools together through integrations."

Louis B., G2

Voici à quoi ressemble un enregistrement une fois qu'on est dedans. Remarquez les champs qui font le travail de routage, Assigned to et Assignment group, tous deux hérités directement de task :

Une requête, trois numéros de ticket

C'est là que le premier jour tourne mal, pour presque tout le monde.

Quelqu'un demande un ordinateur portable. Dans un système de tickets classique, c'est un ticket, et dans la plupart des systèmes de tickets internes, ça reste un seul ticket jusqu'à la livraison. ServiceNow en fait trois types d'enregistrement, car Request Management modélise délibérément la demande, l'article et le travail comme des éléments distincts :

1. REQ sur sc_request, le conteneur au niveau du panier. Un checkout donne un REQ.
2. RITM sur sc_req_item, un par article du catalogue. Un ordinateur portable et un écran dans le même checkout signifient un REQ portant deux RITM.
3. SCTASK sur sc_task, le travail d'exécution lui-même, généré par le flux du RITM. L'acheter, l'imager, puis l'expédier : trois SCTASK à partir d'un seul RITM.

Ainsi, une seule personne demandant une seule chose peut facilement produire cinq enregistrements répartis sur trois séries de numéros, avec trois endroits distincts où aller vérifier un statut. Ce n'est pas un bug. C'est la séparation panier, article et travail, construite volontairement. C'est aussi, invariablement, ce sur quoi trébuchent les nouveaux agents :

"At times, especially as a beginner, it may be hard to navigate with all the various levels of a customer ticket--Interactions, Requests, RITMs, SCTasks etc. And then there's the occasional what seems like a bug."

Andrei F., Knowledge Specialist, Capterra

Les articles du catalogue qui génèrent l'essentiel de ce volume sont les plus banals. Les demandes d'accès sont, à elles seules, la plus grande catégorie et celle qui mérite le plus d'être automatisée. Les demandes de matériel et d'équipement suivent de près, et notre guide sur les demandes de matériel les couvre séparément.

Un piège à connaître si c'est vous qui construisez le catalogue : les variables n'existent que sur sc_req_item. ServiceNow le dit clairement : « Les variables ne sont pas prises en charge pour les tables étendues. » Tout ce que l'utilisateur a saisi dans le formulaire du catalogue reste donc sur le RITM, et le faire remonter jusqu'au SCTASK, où le fulfiller peut réellement le voir, est un acte de configuration délibéré. Si vos fulfillers demandent sans cesse « quelle taille d'écran voulaient-ils », c'est la raison.

Le cycle de vie de l'incident, état par état

Les incidents sont la moitié la plus simple. Le modèle d'états est publié dans son intégralité.

Vous avez bien lu, il n'y a ni 4 ni 5. Ce sont des trous laissés par le modèle antérieur à Helsinki, qui comportait trois états d'attente distincts là où il n'y en a désormais qu'un seul, On Hold. L'article de connaissance de ServiceNow lui-même, KB0564465, publie la correspondance et indique exactement ce qui casse : « si vous aviez un workflow déclenché par l'état 5, vous devez le modifier pour qu'il se déclenche à l'état 3, motif 2. »

Voici maintenant la partie qui m'a le plus surpris dans la documentation. ServiceNow déconseille l'installation du modèle d'états moderne sur les instances mises à niveau. Ce qui signifie que de nombreuses instances de production en service depuis longtemps continuent de fonctionner avec l'ancienne forme à cinq états sous une interface moderne. Tout rapport ou workflow écrit à partir d'un numéro d'état brut dépend de la version, c'est donc une vraie question à poser avant d'hériter de l'instance de quelqu'un d'autre.

Trois comportements qui surprennent

La priorité n'est pas une décision de l'agent. Elle est calculée à partir d'une grille 3x3 d'Impact et d'Urgency, et le champ est fourni en lecture seule. ServiceNow le dit directement sur la page des règles de priorité : « Les intervenants individuels sur les incidents ne peuvent pas modifier les règles de priorité. » Un P3 dont tout le monde s'accorde à dire qu'il devrait être un P1 devient une conversation avec un administrateur, pas une liste déroulante.

La fermeture automatique est un job planifié, pas une minuterie sur l'enregistrement. Deux conséquences en découlent. Premièrement, la piste d'audit ment, car « le nom de l'administrateur connecté au moment où le job Autoclose Incidents s'exécute est attribué au champ Updated by. » Deuxièmement, un moniteur d'inactivité « réinitialise cette horloge de fermeture automatique à chaque déclenchement », de sorte qu'une instance exécutant les deux fonctions accumule discrètement des incidents Resolved qui ne se ferment jamais, sans que rien ne fasse remonter le conflit. La solution, selon la documentation de ServiceNow, est une Reset Condition de [Incident state] [is not] [Resolved].

Fermer un parent ne ferme pas ses enfants. Résoudre, si. Fermer, non. Placez cent enfants sous un incident parent de panne réseau, et fermer le parent laisse cent enregistrements Resolved en attente d'appelants individuels, selon la table de synchronisation parent-enfant. Cette asymétrie contribue souvent à un backlog de tickets qui paraît pire sur un tableau de bord qu'il ne l'est réellement.

Comment les tickets sont réellement routés

Le routage repose sur deux champs hérités, assigned_to et assignment_group, ce qui explique qu'il se comporte de la même façon sur chaque type d'enregistrement. Les règles d'assignation les définissent automatiquement dès que les conditions correspondent.

Une règle à propos de ces règles mérite une affiche. Extrait de la documentation sur les règles d'assignation : « Les règles d'assignation ne peuvent pas écraser des assignations existantes (y compris celles définies par une valeur par défaut ou par une règle d'assignation exécutée précédemment). » Une valeur par défaut bien intentionnée sur assignment_group désactive alors silencieusement toute règle de routage écrite par la suite. Et lorsque plusieurs règles correspondent, seule celle avec la valeur d'ordre la plus basse s'exécute. Toujours.

Il existe aussi un piège de permissions, qui ressemble à un bug la première fois qu'on le rencontre : un utilisateur détenant le rôle itil ne peut pas assigner un incident à un groupe portant le rôle admin ou security_admin, ni à aucun groupe dont le parent porte ces rôles.

Pour approfondir la bonne mise en place de cette couche, notre guide sur le routage de tickets par IA va plus loin que ce que je peux faire ici, tandis que l'article complémentaire sur le tagging de tickets par IA couvre la moitié classification. La vue de catégorie plus large se trouve dans notre guide sur le ticketing IT automatisé.

Les SLA, et le champ qui ne fait rien

Le Service Level Management de ServiceNow est solide, et une seule task peut porter plusieurs SLA à la fois, chacun suivi sur son propre enregistrement task_sla. Les utilisateurs l'apprécient :

"The SLA tracking feature is another aspect I like, as it helps our team assess the performance of the person resolving issues."

vignesh m., admin, G2

Deux choses valent la peine d'être connues avant de concevoir vos accords.

Premièrement. La distinction SLA / OLA / Underpinning Contract, à laquelle tout cours ITIL consacre une heure entière, n'est, à l'intérieur du produit, qu'une étiquette. La note de ServiceNow sur le champ Type tient en une seule phrase : « Type est utilisé uniquement à des fins de reporting. » Même moteur, mêmes conditions, calculs identiques. Le champ Target de Response par rapport à Resolution suit la même logique, existant « uniquement à des fins de filtrage, de recherche et de reporting. »

Deuxièmement, les jours ne sont pas des jours ouvrés. La documentation expose clairement le piège : « Le nombre de jours spécifié dans ce champ est converti en blocs de 24 heures. Si le champ Schedule identifie un horaire avec des journées de huit heures, une durée de 1 jour fixe le SLA à une violation trois jours ouvrés plus tard. » Une conception raisonnable. Aussi un moyen très facile de mettre en production un SLA qui dysfonctionne pendant un an avant que quiconque ne le remarque.

Bon à savoir également : sur une instance moderne, Breached n'est absolument pas une étape de task_sla. Les étapes sont In progress, Cancelled, Paused et Completed. Breached ne survit que « pour les systèmes utilisant soit le moteur SLA de 2010, soit fonctionnant en mode de compatibilité », et pourtant le widget visuel du minuteur continue de l'afficher, si bien que les deux vocabulaires ne concordent pas. Construisez du reporting SLA là-dessus, et cette discordance finira par se manifester.

Le libre-service, et ce que le Virtual Agent dévie réellement

Le libre-service est là où se joue l'histoire du volume de tickets, et là où les niveaux commencent à compter.

Le Virtual Agent complet est performant. ServiceNow livre des sujets ITSM préconstruits qui accomplissent un vrai travail. Check IT Ticket Status liste les tickets actifs d'un utilisateur avec leur étape et leur dernière mise à jour. Escalate IT Ticket relève l'urgence d'un niveau, avec une justification obligatoire. Il existe aussi des sujets pour la réservation de salles de réunion et les équipements assignés. La déviation elle-même est définie strictement, comme « lorsqu'un utilisateur pose une question ou fait une demande qui n'aboutit ni à un ticket ni à une assistance humaine. »

Virtual Agent Lite, ce que reçoivent les clients des niveaux inférieurs, est un animal différent. Deux sujets sont livrés avec, Check Ticket Status et Report an Issue. Aucun NLU du tout, seulement de la correspondance par mots-clés. On ne peut pas ajouter de sujets ni de canaux. Et surtout, il n'a aucun tableau de bord d'analyse, donc aucun moyen pris en charge de mesurer combien il a dévié. Évaluer la déviation sur Lite revient à évaluer quelque chose que l'on ne peut pas mesurer, ce qui vaut la peine d'être su avant de le comparer à n'importe quel chatbot de service desk qui, lui, rapporte un taux de résolution. Les équipes qui se heurtent à ce mur finissent généralement par regarder du côté des alternatives à Virtual Agent.

Une autre contrainte mord en production. Transférer vers un humain nécessite un humain. « Au moins un agent en direct doit être disponible lors d'un transfert depuis Virtual Agent, sinon l'utilisateur final voit un message no agents available et sa conversation n'est pas transférée. » Aucun repli de ticket documenté n'existe sur ce chemin, exactement le moment où un bon design de transfert IA compte le plus.

La prise en charge des e-mails a sa propre version du problème. La classification en tant que transfert l'emporte sur le filigrane, si bien que ServiceNow « classe tout e-mail répondant à ces critères comme un transfert, même si le message contient un filigrane ou un numéro d'enregistrement qui le classerait autrement comme une réponse. » En clair, transférer un fil d'e-mails vers ServiceNow crée toujours un ticket en doublon.

Ce que coûte un système de tickets ServiceNow en 2026

Voici maintenant la partie pour laquelle tout le monde est vraiment venu.

ServiceNow n'affiche aucun prix, c'est pourquoi notre guide des prix ServiceNow existe tout court. J'ai revérifié la page de tarification ITSM le jour même de la rédaction. Trois offres, Foundation, Advanced et Prime. Un seul bouton indiquant « Get Custom Quote ». Aucun symbole monétaire nulle part sur la page. Les seuls chiffres de toute la matrice comparative sont les limites de capacité pour les tables App Engine Starter et les enregistrements Process Mining.

Depuis le 9 avril 2026, les anciens niveaux Standard, Pro, Pro Plus, Enterprise et Enterprise Plus ont disparu, les SKU historiques ayant atteint la fin de commercialisation le 1er juillet 2026. Foundation, Advanced et Prime constituent désormais la seule structure qu'un nouvel acheteur voit jamais.

Lisez la ligne IA deux fois. Elle résume tout l'empaquetage en une seule ligne. L'IA qui clôture réellement un ticket sans humain est réservée à Prime. Foundation et Advanced obtiennent à la place une IA assistive : résumés, brouillons, un chatbot. Un MVP ServiceNow écrivant sur la communauté dit la même chose à propos des constructions personnalisées, que Prime « est le seul niveau qui permette de créer des compétences IA et des agents IA entièrement nouveaux sur la plateforme. » Ainsi, AI Agent Studio est une fonctionnalité du niveau supérieur plutôt qu'une fonctionnalité de la plateforme dans son ensemble, et le panorama de coûts plus complet se trouve dans notre décomposition des prix de l'IA ServiceNow.

La séparation apparaît aussi dans le marketplace de ServiceNow lui-même, où le L1 IT Service Desk AI Specialist se trouve à côté du filtre de persona nommant Fulfiller comme sa propre classe sous licence :

Qui vous payez réellement

C'est l'unique fait qui rend la question « combien coûte ServiceNow » réellement répondable. Pour l'ITSM, la facturation se fait sur le rôle Fulfiller. Un employé de ServiceNow rédigeant le guide de licence le définit comme « vos agents de service desk principaux, gestionnaires de cas et propriétaires de workflows. Toute personne qui travaille activement et résout des enregistrements », comptés comme des utilisateurs actifs connectés au cours des 365 derniers jours.

Les requesters, c'est-à-dire les employés qui créent les tickets, ne sont pas comptés. Un avantage réel par rapport aux outils facturés au siège, et le même type d'économie qui rend Jira Service Management moins cher que Jira classique pour un usage support.

Puis arrivent les deux exceptions.

Un manager qui se contente d'approuver compte comme un Business Stakeholder mesuré séparément, pas comme un utilisateur gratuit. Et certains produits facturent selon le modèle Unrestricted User, où chaque utilisateur actif de l'instance compte. HRSD et Employee Center Pro appartiennent tous deux à ce groupe. Ainsi, l'économie « les requesters sont gratuits » s'évapore le jour où l'on achète le bon portail, ou le jour où les RH veulent y participer.

L'ampleur de cette décision n'est pas négligeable. Un ServiceNow Certified Technical Architect écrit publiquement :

"In the world of ServiceNow platform governance, one decision stands above the rest in terms of financial impact: choosing between the Fulfiller (Named User) and the Unrestricted User model. As a ServiceNow Certified Technical Architect (CTA), I've seen this single choice result in a $780,000 variance in spend over a standard 3-year contract."

Bill Martin, ServiceNow Community

Puis un employé de ServiceNow apparaît dans les commentaires pour corriger la lecture erronée courante de l'alternative :

"One quick correction though: Unrestricted Users (UU) aren't actually flat fee. They're still user-based. The "unrestricted" part means unlimited roles within the module, but if the customer's sys_user table grows, they're buying more UU licenses."

Lenny Leppers, ServiceNow Community

Deux autres pièges du même architecte, dont aucun n'apparaît sur une quelconque page de tarification. La licence est par instance, donc des instances séparées pour l'Amérique du Nord et l'EMEA doublent la facture. Et il chiffre les utilisateurs fantômes à « 20-25 % des licences ServiceNow » dans les grandes entreprises, face à une hausse annuelle de 7 à 12 %. Notre guide des types de licence parcourt l'ensemble si vous êtes en pleine négociation.

Le compteur d'assists, désormais public

Voici la nouveauté. Le 23 juillet 2026, ServiceNow a publié le Now Assist Overview sous forme de document juridique, et la grille tarifaire par action est venue avec. Jusqu'à huit jours avant la rédaction de cet article, aucun de ces chiffres n'était public.

Un assist est « une unité utilisée pour mesurer l'usage des compétences Now Assist via les actions de compétence effectuées », et il est consommé « que ce soit en instance de production ou de sous-production. » Les droits sont regroupés au niveau du compte et se réinitialisent à la date anniversaire de l'achat plutôt qu'à l'année civile. Les dépasser, et « ServiceNow peut facturer au client l'usage excédentaire. »

L'écart, sur trois ordres de grandeur, est ce qui frappe le plus :

Un « workflow agentique » se termine à la complétion, à 20 actions, ou après une heure d'inactivité. Tout ce qui dépasse ces 20 actions démarre un nouveau workflow facturable. Un seul ticket peut donc vous en coûter deux.

La phrase à laquelle je reviens sans cesse vient d'un guide pratique ServiceNow : « La surprise, pour la plupart des équipes, est que la consommation la plus lourde ne vient pas des utilisateurs qui tapent des prompts. C'est l'automatisation qui tourne en arrière-plan. » Il cite quatre sources de consommation silencieuse. Virtual Agent basculant vers Now Assist sur un sujet non reconnu, la synthèse d'espace de travail se déclenchant à l'ouverture d'un case, les compétences personnalisées Skill Kit, et les instances de sous-production. ServiceNow a livré des interrupteurs d'urgence et des alertes de pics en juin 2026 pour contenir tout cela, avec une consigne documentée de ne pas désactiver les notifications car « les environnements de sous-production consomment eux aussi des assists ! »

ServiceNow ne publie aucune taille de pool pour les nouveaux niveaux, donc appliquez vos propres chiffres à la dernière allocation qu'il a effectivement publiée : 6 000 assists par fulfiller par an, sous l'ancien modèle Pro Plus.

Déplacez le curseur de l'agent autonome de 5 % à 15 % et observez ce qui se passe. Ce seul geste résume toute la différence entre l'IA assistive et l'IA autonome pour laquelle vous avez acheté Prime. C'est aussi pourquoi je voudrais une prévision d'assists écrite pendant la discussion contractuelle, pas après.

Ce que les gens disent vraiment de leur expérience

Je veux être honnête ici. Il est facile de fabriquer un règlement de comptes à partir d'une recherche de plaintes.

Le corpus ne le permet pas. ServiceNow ITSM affiche 4,5 sur 5 sur 1 915 avis sur G2, dont 70 % à cinq étoiles et, fait notable, zéro pour cent à une étoile. Capterra le classe à 4,5 sur 352 avis. Personne de sérieux ne soutient que le modèle incident, changement et CMDB est erroné.

Ce qu'ils disent, c'est que c'est lourd. Les propres décomptes de tags de G2 placent Ease of Use comme l'attribut le plus loué avec 168 mentions, juste devant Learning Curve (72), Expensive (60) et Complexity (56). Cette tension est le résumé honnête du produit.

Sur l'expérience au quotidien :

"There's a lot of clicks which takes a long time"

Chris C., G2

Sur la montée en compétence, de la part d'un développeur qui lui a quand même donné 4,5 sur 5 :

"ServiceNow IT Service Management is huge, and when I started as a developer, it took months to really understand how everything connects like tables, scripts, workflows, ACLs. The documentation exists but is scattered, and half the time, you end up finding answers in community forums instead of official docs."

Shruti C., Developer, G2

Et la métaphore la plus percutante de tout l'ensemble, issue d'une implémentation qui a clairement mal tourné :

"Imagine you go to a car dealer to buy a new car. You pay the money and you get the keys. When you get outside to pick your new car you see a bunch of parts in a pile. So if you want to drive your car you need to put it together."

Verified User in Insurance, G2

Le contrepoids, et je pense que c'est la chose la plus vraie que quiconque ait dite dans cet ensemble : l'opinion de la plupart des gens sur ServiceNow est en réalité une opinion sur l'implémentation de quelqu'un d'autre. Un commentateur de Hacker News l'a formulé ainsi : « une instance bien gérée peut voler », et a attribué la plupart des mauvaises expériences à des clients « traînant un code horrible et des applications LCNC mal conçues. » Cela correspond à ce que j'observe. La plateforme est rarement le problème. Le formulaire à 400 champs que quelqu'un a construit dessus l'est généralement.

Où il trouve sa place, et où je ne l'utiliserais pas

ServiceNow est le bon choix quand les tickets ne sont pas le cœur du sujet. Si ce dont vous avez besoin, ce sont des incidents liés à une CMDB, une gestion des changements avec une véritable autorisation CAB, des enregistrements de problème qui survivent aux incidents qui les ont déclenchés, plus un unique moteur de workflow couvrant l'IT, le support RH et les installations, rien dans le marché intermédiaire n'y touche. Face à face contre Freshservice, cette étendue constitue tout l'argument. À cette échelle, ça vaut l'argent.

Je ne l'achèterais pas juste pour faire tourner une file. Si tickets qui entrent, tickets qui sortent est tout le travail, vous paierez le prix d'une plateforme d'entreprise pour une fraction de la plateforme, et la plainte de l'outil de ticketing coûteux s'écrit d'elle-même. Un commentateur de Hacker News a décrit un CIO faisant exactement cela : remplacer un tracker existant pour seulement deux files, sans CMDB ni gestion des changements, pour « 128k par an. » Si c'est la forme de votre besoin, notre comparatif pour petites équipes ou les options open source sont la réponse honnête.

Le troisième cas est le plus intéressant, et c'est là que se trouve réellement la plupart des lecteurs de cet article. ServiceNow est déjà installé, il ne va nulle part, et la file continue de croître. L'arracher n'est pas envisageable. Ajouter un niveau Prime pour qu'un spécialiste IA puisse clôturer les tickets de niveau un est une discussion budgétaire assortie d'un compteur non publié. Il reste donc un seul levier, le même sur lequel finit par atterrir tout projet d'IA pour help desk IT : la déviation à la prise en charge.

Essayez eesel devant votre file ServiceNow

Laissez-moi être direct sur ce que je propose et ne propose pas ici. La version honnête est de toute façon plus utile.

eesel n'est pas un plugin ServiceNow. Il n'y a aucune intégration ServiceNow sur notre page des intégrations, et je préfère le dire ici plutôt que de vous laisser le découvrir à mi-parcours d'un essai.

Ce que fait eesel, c'est se positionner un cran plus tôt, sur les canaux où les questions IT naissent réellement. Il répond dans Slack, dans Microsoft Teams et par e-mail, avant que quiconque n'ouvre un formulaire. Les connaissances à partir desquelles il répond sont la documentation que vous avez déjà écrite, où qu'elle vive aujourd'hui : Confluence, Google Docs, Notion, un centre d'aide.

Je construis les agents qui font ce travail, donc le mécanisme compte pour moi. L'agent recherche dans votre documentation réelle, répond quand il en a le fondement, et reste silencieux quand ce n'est pas le cas. Cette dernière partie est tout le jeu. Après avoir vu un bot à l'air confiant donner de mauvaises réponses sur une file en production, nous simulons désormais chaque déploiement contre des tickets historiques avant qu'il ne touche jamais une vraie personne, et tout ce qui est en dessous du seuil de confiance s'escalade plutôt que de deviner.

Le chiffre que je mettrais en avant n'est pas le nôtre. Jason Loyola, Head of IT chez InDebted, fait tourner eesel comme premier intervenant sur son desk IT interne, et les résultats sont publics : 15 % des problèmes entrants entièrement déviés aujourd'hui, avec 55 % comme objectif à mesure que les connaissances sont réécrites à partir des tickets résolus. Sa propre description de la mise en place : « Ça agit essentiellement comme le ferait un agent. »

Deux limites supplémentaires, car vous devez les connaître avant d'essayer. Cela ne résoudra pas un problème de documentation. Si la réponse à « comment obtenir un nouvel ordinateur portable » n'est écrite nulle part dans votre base de connaissances interne, aucune IA ne va l'inventer. Et c'est une couche, pas un remplacement, donc votre modèle d'incident, de changement et de CMDB reste exactement là où il est. La tarification fonctionne par ticket traité plutôt que par siège, ce qui signifie au moins que la facture ne grimpe pas à chaque embauche IT.

Vous pouvez l'essayer gratuitement et le diriger vers les questions auxquelles votre service desk répond cinquante fois par mois, puis voir combien d'entre elles avaient réellement besoin d'un ticket.