vendredi 29 juin 2007

Triangles

Je suis en train de travailler sur un assez gros projet chez AXA.

Je vous explique ce qu'est un triangle. En gros, disons à chaque semestre, on accumule des données sur les sinistres qui se sont produits. Disons que l'on regarde combien on a déboursé d'argent depuis le deuxième semestre en 2006 (2006-2). Donc, en décembre 2006, on a regardé combien on a payé pour des sinistres de juillet à décembre.

Maintenant, en juin, on regarde combien on a payé POUR LES SINISTRES ENCOURRUS PENDANT 2006-2. Mettons qu'on avait payé 600K, et que là on soit rendu à j'sais pas... 800K. Ça veut dire qu'on a payé 200K pendant le dernier semestre, pour les sinistres du dernier semestre en 2006.

Plus le temps avance, plus on a de l'information sur les semestres passés, combien on a payé, etc. etc. Après un certain nombre de semestres / d'années, on est "certain" qu'on a tout payé.

Ensuite, on fait des études là-dessus. On regarde par exemple, "si on a payé 10K dans le premier semestre, combien doit-on s'attendre à payer d'ici 15 ans pour ce semestre-là?".

Voici à quoi pourrait ressemble un triangle (pour ce qui est payé):





Ici, si on regarde la dernière ligne, par exemple, ça veut dire que pendant le dernier semestre de l'année 2006, on a payé 15 000$ en dommages et frais et autres pour ce semestre-là. Si on continue à monter sur la diagonale, le "21" vis-à-vis 2006-1 et 12, ça veut dire qu'après 12 mois (depuis janvier 2006), on a payé un total de 21 000$ pour les accidents survenus entre janvier et juin 2006 (premier semestre).

Certains constateront que "à chaque 6 mois, on peut rajouter une diagonale!". Mais à quoi ça sert? En gros, ça sert à estimer des "loss development factors". Par exemple, on pourrait avoir un facteur "à l'ultime", qui nous permettrait d'estimer après 1 semestre combien on déboursera en tout pour cette période d'accidents-là. Par exemple, le LDF à l'ultime pour 2001-1 serait ~ 2.6. En effet, au premier regard on avait 10 000, et on dirait que le total s'est stabilisé à 26 000. A posteriori, on observe facilement qu'on obtient 26 000 en multipliant 10 000 par 2.6. Si on avait su a priori, ç'aurait été cool... donc, c'est ça qu'on essaie de faire... on essaie d'obtenir des données de même pour pouvoir faire de meilleures estimations. Aussi, des LDF peuvent être développés pour n'importe quelle quantité de semestres... je dis "à l'ultime", mais j'aurais pu dire 18 mois ou quelque chose du genre... c'est le même principe.

Bon, le problème survient justement quand on veut construire cette diagonale-là. Premièrement, on joue avec des bases de données complètement incompréhensibles et indéchiffrables (si je vous dit qu'il y a 60 000 enregistrements, et que chaque enregistrement a ~ 48 variables, je pense que ça vous donne une petite idée ;)).

La manière que ça fonctionnait avant, c'est qu'on faisait rouler des programmes dans un logiciel, puis on se servait d'un autre logiciel pour utiliser ces résultats-là et on faisait des opérations "fastidieuses" pour obtenir certaines données, qui ELLES étaient finalement envoyées dans Excel, et là fallait faire plein d'affaires que j'ai jamais compris. En fait, y'a pas grand-monde là-bas qui font des triangles, et seulement "quelques-uns" semblent vraiment savoir de quoi ils parlent... mais c'est vraiment compliqué comme processus / procédure.

Ce que je suis en train de faire, c'est de simplifier le tout. J'ai modifié / écrit des programmes qui permettent de sauter l'étape du deuxième logiciel... et les données sortent directement dans un fichier Excel. J'ai développé un outil dans Excel qui se "feed" sur ces données-là directement, et tous les triangles de toutes les lignes d'affaires d'une compagnie sont construits en un gros 45 secondes, et envoyés directement vers la base de données. J'ai aussi rajouté une petite interface qui permet de modifier manuellement les triangles, tout à coup qu'on ait des opérations / ajustements à faire dessus. C'est assez chouette.

Bon... le problème, c'est de modifier les programmes qui permettent de générer ces données. Il y a 4 compagnies... la première compagnie, ça a bien été. La deuxième compagnie, c'était l'enfer... parce que celle-là avait des triangles semestriels (classiques) mais aussi trimestriels... et il fallait que le programme gère les deux à la fois, et c'était bordélique et affreux. En fait, le programme, au départ, ne gèrait pas les triangles semestriels... il fallut que je l'adapte en conséquence (pas le fun pour une miette). La troisième compagnie, facile as fuck... alors la quatrième, qui est petite et sans importance, je me suis, my god ça va être facile.

Ouais ben... grossière erreur. J'ai commencé cette compagnie-là mardi. Je l'ai "finie" (débloquée serait le meilleur mot) seulement cet après-midi (j'étais content as shit). Le problème, c'est qu'il y a deux "types" de données: des données incrémentales, et des données cumulatives. À titre d'exemple, dans le triangle, si on prend la ligne 2006-1, on a ces deux données: 16 et 21. Pour obtenir le 21, i.e. celui de la diagonale, on pourrait soit: générer "21" comme résultat (cumulatif), ou encore générer "5" (16 + 5 = 21)(incrémental).

Dès le départ, j'ai développé absolument tout à partir de données incrémentales. Toute l'interface en fait fonctionne strictement avec des données incrémentales... mine de rien, switcher d'incrémentales à cumulatives, c'est pas SI agréable que ça, surtout s'il n'y a qu'une seule compagnie qui fonctionne de même. ;)

Mais c'était pas mon plus gros problème. Non seulement j'avais des données cumulatives, mais aucune de mes données ne fonctionnaient! :) Ça m'a pris un temps fou pour comprendre pourquoi... il me manquait une criss de variable. Ah ben oui, avec 48 variables, certaines que tu gardes d'autres que non, et qui changent de noms d'une compagnie à l'autre, C'EST PAS SI FACILE QUE ÇA LE SAVOIR.

Bon, et là j'avais la grosse question: j'ai des données cumulatives, comment les transformer en incrémentales.

La question est bête... mais j'étais pogné dans mon monde. J'essayais de me dire qu'il y aurait moyen de faire une petite passe-passe dans Excel, d'y dire que "si c'est telle compagnie, alors load-moi le triangle, enlève l'ancienne diagonale, puis utilise ces données-là pour faire la nouvelle diagonale". Mais c'était typiquement inutile, et puis c'est pas "clean" -- je préfèrais que toutes les compagnies soient uniformes.

J'ai passé plusieurs heures à essayer de trouver une solution simple. Et là j'ai eu l'idée enfantine de ma vie: Si je suis capable de calculer la diagonale de décembre... je vois pas pourquoi je serais pas capable de calculer la diagonale à juin (c'est-à-dire l'ancienne diagonale). Et si je suis capable de fausser les données, de faire à croire à l'ordi que juin est en décembre, et que toutes ses valeurs sont négatives, et que j'additionne les deux ensemble... TADA! DONNÉES INCRÉMENTALES LES AMIS!

Bon, dit de même, ça a l'air compliqué... mais en 10 minutes, tout était parfaitement usitionnel. Alors, aujourd'hui, j'ai terminé la quatrième compagnie. :) J'étais tellement content. Ça me stressait beaucoup beaucoup. J'y pensais tout le temps. Quand je me couchais, j'essayais de trouver une solution, de voir quoi faire... et là je suis content que ça ait débloqué.

Disons-le, j'ai pas crissé grand-chose de l'après-midi après ça... mais j'ai quand même trouvé le moyen d'améliorer un peu mon outil, de le rendre plus efficace, des conneries de même qui font que je perds pas totalement mon temps.

Vous savez, ça a l'air de rien... mais il y a quelque chose d'honnêtement récompensant quand on regarde le résultat final. Parce que tout est rendu si simple. On change quelques valeurs (quelle date sommes-nous? où se trouve la base de données? ...), et on clique sur un bouton. On copie/colle ces données-là dans une page dans Excel, on change quelques paramètres (quelle date sommes-nous? quelle compagnie traitez-vous?), et on clique sur un bouton, et BANG... 75 triangles sont construits, on sauvegarde, on quitte, et c'est fait! N'importe qui, avec une procédure de 1 page, pourrait faire ça. Pas besoin d'être actuaire. Ce qui fait que 1) l'adaptation est beaucoup plus facile, et 2) le temps est grandement optimisé, de telle sorte qu'il reste beaucoup plus de temps pour faire de l'analyse plutôt que juste des opérations pour créer des résultats.

C'est pour ça que je tiens à bien faire ma job. Parce que si je suis capable de prévoir le plus de problèmes possibles avant qu'ils ne surviennent, alors tout le monde s'en portera mieux, et tout le monde va être content que quelqu'un quelque part ait pris le temps de développer ce monstre-là.

6 commentaires:

Anonyme a dit...

Bon okay t'As raison ctait pas vrmt intéressant.. je l'ai pas lu. On taime pareil.. ^^'

Anonyme a dit...

Keep up the good work. C'est vraiment nice ça. Je sais pas si je suis le seul à trouver ça nice (actuariat), jveux pas avoir un point de vue biaisé. En passant, cté en quel language que t'as programmé ça?

Amine.

Seigneur a dit...

Hmmmm.

Les données sont obtenues à partir de programmes SAS, et la macro est écrite en visual basic dans Excel.

Anonyme a dit...

ok, mais je réitère lol, c fort en pareil ton truc

amine.

Seigneur a dit...

Bah, merfi :P

On avait vu ça en IARD en première session, je sais pas si tu te rappelles... genre son affaire de LDF pi toute ça... mais osti kiétait pas clair, genre sérieusement tout ce que j'ai appris, je l'ai appris au bureau, vraiment pas à l'école... lol

Anonyme a dit...

ouais, je m'en rappelle. lol. Sérieusement, pour l'exam, ces calculs là, je les avais mémorisés et un peu oubliés tout de suite après. Avec sa ligne du temps au tableau incompréhensible...enfin ça fait du bien de comprendre le LDF grâce à ton article.

P.S. J'espère que c'est pas ce prof là qu'on va repogner en IARD II lol.

amine.