1.2 Données typiques en IARD

Sur la page Moodle du cours, une base de données d’assurance I.A.R.D. fictive a été déposée. La forme des données est typique de ce qu’on peut avoir chez un assureur. Le nom des colonnes a été changé, et les statistiques de réclamations ont été aussi modifiées. Néanmoins, le jeu de données résultant est très utile pour bien comprendre avec quoi les actuaires en assurances IARD peuvent travailler.


Pour jouer avec les données, il suffit de télécharger la base de données sur son ordinateur et d’utiliser la fonction load() de R pour y accéder, en pointant vers l’endroit ou la base de données a été sauvée:

load('Data/dbfictif.Rda')

Dans le baccalauréat en actuariat, vous aurez un cours d’informatique pour apprendre en détails le langage R, soit le ACT3035: Laboratoire d’actuariat. Dans ce cours d’introduction, afin de pouvoir analyser un peu des données réelles, quelques fonctions de base en R seront introduites.

Pour les étudiants intéressés, on peut consulter ce petit document simple produit par un collègue de l’Université Laval

https://cran.r-project.org/doc/contrib/Goulet_introduction_programmation_R.pdf

Dans tous les cas, le but du cours n’est pas d’apprendre R et vous ne serez pas évalués à ce sujet. Toutefois, pour mieux comprendre les côtés pratiques du cours, il peut être intéressant de se familiariser avec ce logiciel.


Pour débuter, on peut extraire quelques informations de base du jeu de données avec quelques fonctions:

c(nrow(db.fictif), ncol(db.fictif))
## [1] 386883     32

Cela nous indique le nombre d’observations de la base de données, et le nombre de colonnes. Bien que plus de 350000 observations puisse sembler impressionnant, les base de données actuelles en assurance IARD au Canada sont souvent beaucoup plus grosses.


On peut regarder les premières lignes d’un jeu de données, et spécifier les numéros de colonnes.

db.fictif[1:10, c(1:5,7,8)]
## # A tibble: 10 × 7
##    policy_no veh.num renewal_date debut      fin        nb.sin Tot.Cost
##        <dbl>   <int> <date>       <date>     <date>      <int>    <dbl>
##  1   6000088       1 2015-11-10   2014-11-10 2015-11-09      0       0 
##  2   6000088       1 2016-11-10   2015-11-10 2016-11-09      1     186.
##  3   6000274       1 2011-02-03   2010-02-03 2011-02-02      0       0 
##  4   6000274       1 2012-02-03   2011-02-03 2012-02-02      0       0 
##  5   6000274       1 2013-02-03   2012-02-03 2013-02-02      0       0 
##  6   6000274       1 2014-02-03   2013-02-03 2014-02-02      0       0 
##  7   6000274       1 2015-02-03   2014-02-03 2014-12-28      0       0 
##  8   6000274       2 2016-02-03   2015-03-13 2016-02-02      0       0 
##  9   6000274       2 2017-02-03   2016-02-03 2017-02-02      0       0 
## 10   6000274       2 2018-02-03   2017-02-03 2018-02-02      0       0

On y liste ainsi tous les contrats. de la date du début à la date de fin. Pour chacun des contrats, on y voit aussi le nombre de sinistres survenus et le coût total du sinistre. Pour l’ensemble de la base de données, il devient donc possible de calculer la somme totale du nombre de sinistres, et la somme des coûts de tous les sinistres.

sum(db.fictif$nb.sin)
## [1] 73703
sum(db.fictif$Tot.Cost)
## [1] 488171982

En moyenne, pour un contrat, on peut même calculer le nombre de sinistres moyens (fréquence), le coût moyen d’un sinistre (sévérité) et même en moyenne ce que coûte un contrat (charge pure).

frequence <- sum(db.fictif$nb.sin)/nrow(db.fictif)
severite <- sum(db.fictif$Tot.Cost)/sum(db.fictif$nb.sin)
charge.pure <- sum(db.fictif$Tot.Cost)/nrow(db.fictif)

c(frequence, severite, charge.pure)
## [1]    0.1905046 6623.5021893 1261.8077865

Ainsi, une approche simpliste du travail d’un actuaire serait simplement de demander une prime annuelle de 1261.81$ à tous les assurés pour avoir une couverture d’un an. De cette manière, ce qui survient dans le futur est exactement comme ce qui s’est passé dans la base de données, la somme des primes collectées sera égale à la somme de sinistres.

Bien que le passé nous soit très utile, supposer que ce qui est survenu dans le passé sera identique au futur est naif.


De plus, tous les individus ne sont pas égaux devant le risque et il convient de charger une prime plus élevée aus assurés les plus risqués et une prime plus basse aux assurés qui sont les plus prudents.

Par exemple, on pourrait calculer la prime des assurés en fonction de leur alimentation:

library(dplyr)

db.fictif %>%
  group_by(alimentation) %>%
  summarise(frequence = sum(nb.sin)/n(),
            severite = sum(Tot.Cost)/sum(nb.sin),
            charge.pure = sum(Tot.Cost)/n())
## # A tibble: 3 × 4
##   alimentation frequence severite charge.pure
##   <chr>            <dbl>    <dbl>       <dbl>
## 1 Carnivore        0.259    7170.       1859.
## 2 Végétalien       0.211    6558.       1386.
## 3 Végétarien       0.177    6585.       1164.

On y voit que les assurés carnivores coûtent en moyenne beaucoup plus chers que les assurés végétaliens. Similairement, en fonction de la couleur des cheveux, nous avons:

library(dplyr)

db.fictif %>%
  group_by(cheveux) %>%
  summarise(frequence = sum(nb.sin)/n(),
            severite = sum(Tot.Cost)/sum(nb.sin),
            charge.pure = sum(Tot.Cost)/n())
## # A tibble: 4 × 4
##   cheveux frequence severite charge.pure
##   <chr>       <dbl>    <dbl>       <dbl>
## 1 Bleus       0.195    6035.       1174.
## 2 Blonds      0.190    6710.       1273.
## 3 Bruns       0.191    6604.       1259.
## 4 Roux        0.191    6602.       1261.

La différence est moins marquées ici que pour l’alimentation…

Est-ce une différence statistiquement significative? Ce sera à étudier pendant vos études en actuariat. L’exercice de trouver des variables explicatives significatives pour calculer des primes selon le profil de l’assuré est appelé le travail de segmentation.


Pour compléter ce petit survol, la fonction colnames() liste la totalité des colonnes de la base de données.

colnames(db.fictif)
##  [1] "policy_no"       "veh.num"         "renewal_date"    "debut"           "fin"             "expo"            "nb.sin"          "Tot.Cost"       
##  [9] "freq_paiement"   "annee_veh"       "sexe"            "an_naissance"    "annee_permis"    "langue"          "type_prof"       "type_voiture"   
## [17] "type_territoire" "utilisation"     "voiture"         "couleur"         "myopie"          "alimentation"    "cheveux"         "Cost1"          
## [25] "Cost2"           "Cost3"           "Cost4"           "Cost5"           "Cost6"           "Cost7"           "ID"              "Type"

Vous pourrez donc voir aussi, de votre côté, quelles sont les caractéristiques de l’assuré les plus importantes parmi celles que nous avons de disponibles. On voit d’ailleur qu’on ne pourrait pas segmenter la prime d’assurance en fonction de la taille et du poids de l’assuré car ces variables n’ont pas été collectées. Ainsi, une première limitation dans le travail de l’actuaire est d’avoir en main des données intéressantes!