Le recueil des besoins DDA dans un logiciel : ce qui doit être tracé

Ce que cet article ajoute au précédent

Nous avons déjà écrit ce que le Code des assurances exige : l’article L. 521-4 et ses quatre obligations, le régime renforcé de l’assurance-vie, la question du support de l’article L. 521-6, et le fait que la charge de la preuve pèse sur le professionnel. Cet article-là traite du texte ; celui-ci traite de la trace. Autrement dit : une fois qu’on a accepté d’écrire, qu’est-ce qu’un logiciel doit enregistrer pour que l’écrit vaille quelque chose deux ans plus tard ?

La question n’est pas théorique. Un recueil informatisé peut être complet, propre, imprimable — et ne prouver strictement rien, parce qu’il ne dit pas qui a rempli quoi, ni quand il a été figé, ni s’il a été remis.

Un recueil n’est pas un formulaire, c’est un instantané daté

La différence tient en une phrase : un formulaire décrit un état actuel, un recueil décrit un état à une date. Ce qui compte devant un litige, ce n’est pas ce que le dossier contient aujourd’hui, c’est ce qu’il contenait au moment où le conseil a été donné. Un enregistrement qui se met à jour en place efface, à chaque modification, la seule chose qui prouvait quelque chose.

C’est pourquoi un recueil sérieux se fige. Après quoi il ne se corrige plus : il se remplace par une version suivante, qui dit ce qui a changé. Ce n’est pas de la rigidité administrative, c’est la seule façon de pouvoir répondre à « que vous avait-il dit exactement, en mars ? ».

Les sept traces qui font la différence

• La provenance de chaque champ. Un champ saisi sous la dictée du client, un champ repris d’une fiche prospect et un champ proposé par une machine ne pèsent pas le même poids. Le logiciel doit savoir lequel est lequel, et l’afficher à côté du champ.
• Les quatre états d’un besoin. « Le client refuse cette garantie », « elle ne le concerne pas », « il veut d’abord savoir combien ça coûte » et « la question n’a pas été posée » sont quatre faits différents. La plupart des formulaires les écrasent en une case à cocher — et effacent ainsi le refus, qui est pourtant la meilleure protection du conseiller le jour où l’absence de garantie lui est reprochée.
• Le vide qui reste vide. Un champ non renseigné doit produire une ligne vide, jamais un « Non » de confort. Un document qui affiche « Non » à une question jamais posée transforme un silence en déclaration du client : c’est plus dangereux qu’un document incomplet.
• Le gel, avec sa date et son auteur. Qui a validé, quand, à la minute. Sans cela, la date du document est celle de son impression.
• La chaîne des versions, avec un motif. Quand les besoins changent, la version précédente ne disparaît pas : elle passe à l’état « remplacée » et reste consultable, et la nouvelle porte la raison du changement. C’est la chaîne qui prouve le suivi dans le temps, pas le dernier état.
• La remise, distincte de la production. Générer un document n’est pas le remettre. Or c’est la remise, avant la souscription, que la réglementation regarde. Les deux dates doivent être enregistrées séparément, avec le canal utilisé — et la date de la première remise ne doit jamais être réécrite : une relance n’est pas une nouvelle remise.
• L’archivage motivé. Retirer une pièce du dossier doit exiger une raison, et laisser une trace datée dans l’historique du client. Personne ne doit pouvoir faire disparaître un recueil en silence.

Ce qu’un pré-remplissage automatique doit prouver

Le pré-remplissage est utile : personne n’a envie de retaper une adresse. Il devient dangereux au moment précis où il touche une déclaration. Une machine qui lit un document et en déduit un régime obligatoire, un antécédent ou un besoin ne recueille pas les besoins du client : elle formule une hypothèse.

La règle qui en découle est simple et un peu contraignante : tant qu’un champ proposé par une machine n’a pas été repris avec le client, le recueil ne doit pas pouvoir être figé. Pas un avertissement, pas une couleur différente — un blocage, avec le nom des champs concernés. C’est plus lent qu’un pré-remplissage aveugle, et c’est le prix d’un dossier qui tient.

Le même raisonnement vaut pour les booléens. Un champ « oui/non » avec une valeur par défaut répond à la place du client à toutes les questions qu’on ne lui a pas posées. Il faut trois états, pas deux : oui, non, et pas encore demandé.

Les questions à poser à un éditeur

• « Un recueil validé peut-il encore être modifié ? » S’il peut l’être, il ne prouve rien. Demandez à voir ce qui se passe quand les besoins changent après la validation.
• « Comment le logiciel distingue-t-il un champ déclaré par le client d’un champ pré-rempli ? » Faites-vous montrer l’écran, pas l’architecture.
• « Que se passe-t-il quand un champ vient d’une lecture automatique de document ? » La bonne réponse bloque quelque chose.
• « Montrez-moi la trace de la remise d’un document au client. » Pas l’envoi du mail : la remise, avec sa date et son canal.
• « Peut-on supprimer un recueil ? » Et si oui, qu’en reste-t-il dans l’historique du client.
• « Un client peut-il avoir deux recueils validés en même temps sur le même produit ? » Si oui, lequel fait foi ?
• « Que produit le logiciel quand un champ n’a pas été renseigné ? » Ouvrez le document généré et regardez la ligne.

Ce que fait ACTUAL DATA

Le recueil s’ouvre depuis la fiche d’un client ou d’un prospect, pour un produit à la fois, en douze rubriques numérotées, et il porte une référence communicable. Chaque champ pré-rempli affiche sa provenance ; un champ encore marqué « proposé par l’IA — à confirmer » empêche la validation, et le message nomme les champs à reprendre. Les besoins se déclarent en distinguant ce que le client veut, ce qui compte pour lui et le niveau visé — trois questions différentes, trois colonnes différentes.

La validation gèle le recueil avec sa date et son auteur ; une personne ne peut avoir qu’un seul recueil validé par produit à un instant donné. Des besoins qui changent créent une version suivante avec un motif obligatoire, la précédente restant consultable. L’archivage exige lui aussi un motif et écrit une note datée dans l’historique. Enfin, la fiche de recueil et le bilan de conseil se génèrent depuis ces données, et la remise est datée séparément de la production, avec son canal — signature électronique, courriel, remise en main propre, courrier, ou signature sur l’extranet de la compagnie.

Un écran de suivi liste par ailleurs les recueils du cabinet, brouillons en tête, avec leur âge, et les signale au-delà de sept jours : un recueil resté en brouillon, c’est un devoir de conseil commencé et jamais clos.

Ce qu’un logiciel ne fera jamais à votre place

Apprécier l’adéquation entre un contrat et des besoins. Un outil peut structurer, horodater, conserver et rappeler ; il ne peut pas décider que ce contrat-là convient à ce client-là. La recommandation et sa motivation restent votre acte professionnel, et votre responsabilité — quel que soit l’éditeur, et quelle que soit la promesse commerciale qu’on vous fait.

Transparence : ACTUAL DATA est éditée par un cabinet de courtage et vend un outil qui trace précisément ce qui est décrit ici. Les éléments produit cités ont été relevés dans la version en production le 7 septembre 2026. Le détail des textes applicables — articles L. 521-4, L. 521-6, L. 522-5 et L. 522-6 du Code des assurances, avec leurs dates de rédaction — figure dans notre article sur le devoir de conseil. Cet article présente une méthode et un logiciel ; il ne constitue pas une consultation juridique sur votre situation.