MyCoris Assur, refondre une assurance déjà en service

Un refactoring de design commence par une liste, pas par une humeur. La mienne tenait en deux colonnes. Les pages à reprendre : l’onboarding, le tableau de bord, les listes de paramètres et de notifications. Les pièces à refaire : les onglets, les boutons, les cartes, les sélecteurs, les champs, les indicateurs de chargement, et jusqu’au bouton retour.

Écrire cette liste avant de dessiner change la nature du travail. On ne cherche plus à améliorer une impression, on traite des objets qu’on peut cocher — et une équipe de développement peut suivre.

Avant de toucher au premier écran, j’ai listé ce qui fait fuir les assurés dans ce secteur, pour que chaque décision ait quelque chose à réparer :

Les démarches complexes, qu’il fallait rendre plus claires à la souscription comme à la déclaration. Les temps de traitement longs. Le manque d’accès aux informations. L’adaptation aux mobiles. Le rappel du renouvellement, encore manuel. Et le suivi des sinistres et du remboursement.

Elles ne viennent pas d’un manuel d’UX, elles viennent du métier. C’est pour ça qu’elles sont utiles : chacune désigne un endroit précis de l’application, et deux d’entre elles ont produit les décisions dont je suis le plus content, aux chapitres 04 et 05.

Avant la première question d’un devis, l’assuré doit lire ceci : en cas de fausse déclaration intentionnelle, le contrat est nul et de nul effet, et les primes versées restent acquises à l’assureur à titre de dommage. C’est l’article 1 du code CIMA, qui régit les assurances de quatorze pays africains.

Aucune application grand public ne fait lire un texte juridique avant de laisser quiconque avancer. Celle-ci le doit. La seule question de design est donc : où le mettre ?

Il a sa propre page, à l’entrée du parcours, avec une barre de progression encore vide derrière lui. Pas une case à cocher sous un bouton, pas une ligne en petits caractères : une étape. On ne peut pas l’esquiver, et on sait qu’on ne l’a pas esquivée — ce qui est exactement ce que la loi demande.

Un devis d’assurance n’est pas un formulaire, c’est un configurateur : auto ou vie, puis la formule — au tiers, tiers +, tous risques — puis le véhicule, puis les garanties qu’on ajoute ou non.

Le vocabulaire, lui, n’est pas négociable. « Puissance fiscale », « zone de circulation » : ces mots viennent du métier et du tarif, pas de l’interface, et les remplacer par des mots plus doux donnerait un devis faux. Le design ne peut pas simplifier les termes. Il peut en revanche simplifier l’ordre, n’en poser qu’un petit nombre par écran, et dire où l’on en est — d’où la barre de progression, présente du premier écran au dernier.

Et le devis se termine en PDF. Ce n’est pas un détail : un devis d’assurance sert à être comparé, montré à un proche, gardé le temps de réfléchir. S’il ne peut pas sortir du téléphone, il ne sert pas.

Une des six frictions était que le rappel de renouvellement restait manuel. La réponse ne demandait pas une notification de plus : elle demandait que l’état du contrat soit visible sans qu’on le cherche.

Chaque contrat porte donc son état sur lui : actif, presqu’à terme, expiré. Et le bouton suit l’état au lieu de rester le même partout : un contrat actif propose son attestation, un contrat qui approche du terme ou qui a expiré propose de le renouveler.

C’est une petite décision et elle fait beaucoup, parce qu’elle déplace le rappel : il n’est plus un message qu’on envoie, il est une propriété de l’objet. L’assuré qui ouvre sa liste voit lequel de ses contrats réclame quelque chose, et quoi.

C’est le parcours qui ne ressemble à aucun autre, et c’est pour ça qu’il m’intéresse le plus. On ne souscrit pas et on ne déclare pas dans le même état. On souscrit tranquillement chez soi, on compare, on réfléchit. On déclare un sinistre dans un mauvais moment, souvent au bord d’une route, parfois en ayant peur.

L’entrée du parcours est donc presque vide : un dessin, une question, un bouton, et une phrase qui dit combien de temps ça prendra. Rien d’autre à décider à ce moment-là.

Ensuite l’application ne demande pas de raconter, elle demande de montrer : des photos, des vidéos, des documents. Et elle nomme lesquels, parce que personne ne sait ce qu’un assureur attend — le rapport de police, les devis de réparation, le permis, les bulletins de santé. Dire « téléversez vos documents » sans cette liste, c’est garantir un dossier incomplet et un délai de plus.

Pour les vidéos, on peut téléverser un fichier ou coller un lien. Une vidéo pèse lourd, et beaucoup de gens l’ont déjà déposée quelque part avant d’ouvrir l’application. Exiger l’envoi, c’est exiger de la connexion que tout le monde n’a pas.

Et le récapitulatif contient ce qui fait de ce formulaire une déclaration d’assurance et non un ticket de support : les tiers concernés, avec leur nom, leur âge et leur état. C’est là que le métier se rappelle au design.

C’est ce qui sépare un refactoring d’un simple rhabillage : l’échelle typographique, les champs dans leurs trois états — au repos, actif, en erreur — les boutons dans toutes leurs variantes jusqu’à l’état désactivé et à l’action destructrice, les cartes de notification, et les lignes de moyen de paiement.

Ces dernières disent où l’application vit : on y paie son assurance par Coris Money ou Orange Money. Une bibliothèque de composants n’est pas un exercice de style, c’est ce qui part à l’équipe de développement — et ce qui fait que le dixième écran ressemble au premier sans qu’on ait eu à le redemander.

Le refactoring a été livré à l’équipe de développement, développé, et publié. MyCoris Assur est sur Google Play, éditée par Coris Invest Group.

C’est le seul de mes projets qui parcourt la chaîne entière : un client réel, un domaine réglementé, un design remis à une équipe qui l’a construit, et une application que n’importe qui peut installer. Les autres s’arrêtent avant l’un de ces maillons.