Questions d'entretien Actuaire

Je commence par traduire le résultat en une question métier qui parle déjà à mon interlocuteur, plutôt que par les rouages du modèle. Par exemple, lors d'une révision tarifaire sur un produit de prévoyance, au lieu de détailler les ajustements de la table de mortalité et le taux d'actualisation utilisés dans le modèle, j'ai présenté les choses ainsi : ce changement fait passer notre ratio de sinistralité de 78 % à 71 %, et voici l'effet sur la prime d'un assuré type. J'utilise autant que possible un seul graphique, souvent un diagramme en barres ou en cascade montrant le passage de l'ancienne à la nouvelle hypothèse, et j'évite le jargon comme le risque de queue ou la pondération de crédibilité sauf si on me le demande. Je prévois aussi un temps court pour les questions avant de passer à la diapositive suivante, car la première question m'indique souvent si le niveau d'explication était le bon. Devant un conseil d'administration, je commence par la recommandation et le chiffre, puis je détaille seulement si on me le demande.

J'ai validé les examens correspondant au niveau associé, couvrant les probabilités, les mathématiques financières et l'évaluation, dans un parcours proche de celui de l'IFoA ou de la SOA, et je progresse actuellement sur les modules de fellowship avec un objectif d'un examen tous les six mois. J'ai passé mon dernier examen en avril, sur le provisionnement et la modélisation du capital, et j'étudie maintenant celui portant sur la déontologie et la communication, en parallèle d'un poste à temps plein, ce qui veut dire bloquer environ huit heures par semaine sur un créneau fixe plutôt que de chercher du temps au coup par coup. Je tiens un journal de révision et je retravaille les points faibles avec des annales plutôt qu'en relisant le cours, parce que les annales montrent vraiment si on comprend la matière ou si on la reconnaît seulement. Mon employeur prend en charge les frais d'examen et accorde des jours de révision avant chaque session, que je planifie en évitant la clôture trimestrielle.

La clôture trimestrielle, et surtout la clôture annuelle, sont les moments où cette tension est la plus forte, car le délai de reporting ne bouge pas, mais les données nécessaires arrivent parfois en retard ou semblent incohérentes. Ma règle est de signaler un doute plutôt que d'ajuster discrètement un chiffre pour tenir le délai. Lors de la dernière clôture annuelle, un flux de sinistres est arrivé avec ce qui ressemblait à un doublon, deux jours avant l'échéance du provisionnement. J'ai remonté le problème immédiatement à mon responsable et à l'équipe data plutôt que de supposer que c'était négligeable, et nous avons repoussé la validation d'un jour plutôt que d'enregistrer une estimation de provision peu fiable. Quand c'est possible, j'intègre des points de contrôle plus tôt dans le cycle, un calcul préliminaire deux semaines avant l'échéance et un calcul quasi final une semaine avant, pour qu'une anomalie apparaisse avec assez de temps pour l'analyser sérieusement plutôt que le dernier jour.

Mon travail quotidien repose sur un mélange d'Excel, de R et de SQL, avec en plus une plateforme actuarielle dédiée pour le provisionnement lourd et le calcul du capital. J'utilise Excel pour les vérifications rapides et pour tout ce qui part directement dans un support destiné aux parties prenantes, mais je passe sur R dès qu'un modèle doit tourner sur des données au niveau police plutôt que sur des données agrégées, ou dès qu'il faut faire de la simulation, comme une estimation de fourchette de provision par bootstrap. SQL sert à extraire et mettre en forme les données sous-jacentes avant qu'elles n'entrent dans un modèle, et j'ai écrit plusieurs requêtes que le reste de l'équipe réutilise maintenant. La plateforme actuarielle que nous utilisons gère les calculs de capital réglementaire, car reconstruire cela depuis zéro dans un tableur serait à la fois lent et risqué du point de vue du contrôle des versions. Je suis également à l'aise en Python, surtout pour ce qui doit communiquer avec d'autres systèmes ou pour automatiser un rapport auparavant manuel.

Sur un produit d'assurance maladies graves, la tarification reposait sur une hypothèse d'incidence issue de données sectorielles, faute d'un historique de sinistres propre suffisant. Environ dix-huit mois après le lancement, notre expérience réelle a commencé à s'écarter du repère sectoriel, en particulier sur une catégorie de pathologies. J'ai signalé cet écart dès qu'il est apparu dans l'analyse trimestrielle de l'expérience, sans attendre un jeu de données pleinement crédible, et j'ai travaillé avec l'équipe tarification pour modéliser plusieurs scénarios afin de distinguer la part réelle de l'écart du simple bruit statistique lié aux faibles volumes. Nous avons finalement retarifé cette ligne de produit dans les deux cycles de renouvellement suivants au lieu d'attendre la prochaine révision complète, et j'ai construit un tableau de suivi pour qu'un tel écart ressorte automatiquement la prochaine fois plutôt que de dépendre de quelqu'un qui le remarque dans un tableur. La leçon que j'en ai tirée a été d'être plus explicite dès le départ sur le poids qu'on accordait aux données sectorielles et pour combien de temps.

Je faisais une revue par les pairs sur le calcul de provisions d'un collègue pour un portefeuille auto, et le ratio payé sur survenu paraissait décalé pour une année de survenance par rapport au schéma observé sur toutes les autres années. Il s'est avéré qu'il avait appliqué un facteur de développement issu d'une version antérieure du triangle, qui n'avait pas été mis à jour après un rafraîchissement des données. J'en ai parlé directement avec lui d'abord plutôt que de remonter tout de suite à notre responsable, puisque c'était clairement une inattention plutôt qu'autre chose, et nous avons repris la correction ensemble pour qu'il comprenne précisément où cela avait dérapé. Nous avons aussi convenu d'ajouter un contrôle de cohérence simple, en comparant la nouvelle estimation de provision au report du trimestre précédent, pour qu'un tel écart soit repéré plus tôt la prochaine fois. J'ai tout de même informé notre responsable une fois la correction faite, surtout parce que le chiffre de provision figurait déjà dans un projet de dossier pour le conseil et devait être corrigé avant d'aller plus loin.

Lors d'une clôture annuelle, on m'a demandé de finaliser une estimation de provision pour une nouvelle ligne de produit deux jours plus tôt que prévu, pour tenir un conseil d'administration avancé. Les données de sinistres sous-jacentes pour cette ligne étaient encore en cours de nettoyage par l'équipe data, et deux jours de validation en moins me semblaient trop risqués pour un chiffre destiné à un conseil. J'ai expliqué précisément ce qui restait à résoudre, pas seulement mes réserves générales, et j'ai proposé en alternative une fourchette provisoire avec des marges plus larges, ainsi qu'une date à laquelle je pourrais donner un chiffre ferme. Mon responsable a présenté ce chiffre provisoire au conseil avec une date de suivi claire, plutôt que de me pousser à le figer trop tôt. Cela a donné lieu à une conversation un peu délicate sur le moment, mais un chiffre erroné dans un dossier de conseil aurait donné lieu à une conversation bien pire quelques semaines plus tard.

Je pars des méthodes actuarielles classiques, chain ladder et Bornhuetter Ferguson pour le provisionnement des sinistres, en les croisant plutôt qu'en m'appuyant sur une seule, surtout pour les années de survenance les plus récentes et les moins développées, où le chain ladder est le moins fiable. À partir de là, j'ajoute une marge d'incertitude au-dessus de la meilleure estimation, calibrée selon la volatilité historique de cette ligne. Côté capital, dans un cadre type Solvency II, je regarderais comment l'estimation des provisions alimente les provisions techniques puis le capital de solvabilité requis, en vérifiant que les hypothèses utilisées pour le provisionnement et pour le modèle de capital restent cohérentes entre elles, car une incohérence entre les deux est une source fréquente de questions du régulateur. Je m'assure aussi qu'il existe une justification écrite claire pour tout jugement d'expert appliqué au-dessus du résultat mécanique, car c'est généralement la première chose qu'un réviseur externe ou un régulateur demande.

Je commence par extraire les données d'expérience réelle au même niveau de granularité que les hypothèses tarifaires initiales, pour comparer vraiment comparable, plutôt que des chiffres agrégés face à des mailles tarifaires fines. Pour une étude de mortalité, cela veut généralement dire découper par tranche d'âge, sexe et ancienneté du contrat, puis calculer un ratio réel sur attendu pour chaque maille par rapport à la base tarifaire. Je regarde si l'écart se concentre sur un segment précis ou s'il est réparti uniformément sur le portefeuille, car un écart concentré indique plutôt une tendance réelle, alors qu'un écart diffus relève plus souvent du bruit statistique ou d'un problème de données. Je teste aussi explicitement la crédibilité, par exemple avec une approche de fluctuation limitée, avant de recommander tout changement d'hypothèse, en particulier sur les petits segments où quelques sinistres suffisent à faire bouger le ratio de façon significative. Une fois convaincu que l'écart est réel, je modéliserais plusieurs scénarios pour choisir le rythme d'intégration de la nouvelle hypothèse plutôt que de basculer d'un coup.

La plupart de mes modèles partent de données au niveau police extraites via SQL depuis notre entrepôt de données, que je nettoie et valide ensuite dans R avant qu'elles n'entrent dans un modèle, en vérifiant par exemple les numéros de police en double, les dates incohérentes et les écarts par rapport à l'extraction de la période précédente. Je garde l'extraction, le nettoyage et la modélisation dans des scripts séparés et versionnés plutôt que dans un long tableur unique, pour pouvoir isoler l'étape à l'origine d'un problème si quelque chose semble faux, au lieu de tout reprendre depuis le début. Pour tout ce qui doit tourner régulièrement, comme un processus de provisionnement trimestriel, j'automatise le maximum de l'enchaînement afin que le jugement actuariel porte sur la revue du résultat plutôt que sur la reconstruction de la mécanique chaque trimestre. Je suis strict sur la documentation, chaque script a un en-tête expliquant ce qu'il fait et ce qu'il attend en entrée, parce que j'ai hérité d'assez de tableurs non documentés dans des postes précédents pour savoir le temps que cela fait gagner à la personne suivante.