Le recueil des besoins DDA : ce que la loi exige, ce qu’un logiciel doit en garder

L’article L. 521-4 du Code des assurances impose quatre choses avant la conclusion de tout contrat : préciser par écrit les exigences et les besoins du souscripteur, lui fournir une information objective sur le produit, conseiller un contrat cohérent avec ces exigences et besoins, et préciser les raisons qui motivent ce conseil. Le recueil est la première des quatre — celle dont dépendent les trois autres.

Deux précisions comptent au quotidien. La première : le paragraphe III du même article demande que ces précisions soient « adaptées à la complexité du contrat d’assurance proposé » — une garantie accessoire ne se documente pas comme un contrat de prévoyance. La seconde : l’assurance-vie relève d’un régime distinct et plus exigeant, celui de l’article L. 522-5, avec la situation financière, les objectifs d’investissement, les préférences de durabilité et l’expérience du client.

Le détail des textes, leurs dates d’entrée en vigueur, la question du support et celle de la charge de la preuve sont traités dans notre article dédié — devoir de conseil : ce que vous devez pouvoir prouver. Cette page-ci ne les répète pas : elle porte sur ce que ça change dans l’outil.

Tant que personne ne demande rien, les trois se valent. La différence se joue le jour où un client conteste, ou lors d’un contrôle : il faut alors produire l’écrit, montrer qu’il est antérieur à la souscription, et expliquer qui a déclaré quoi.

• Le papier prouve le contenu, pas la chronologie : une fiche non datée, ou datée à la main, ne dit pas quand elle a été figée.
• Le tableur se modifie sans laisser de trace : la version que vous produisez deux ans après n’est pas nécessairement celle que le client a signée.
• Le dossier de mails prouve l’envoi, pas le recueil : un échange épars ne restitue pas un besoin exprimé garantie par garantie.
• Un besoin refusé par le client doit rester lisible comme un refus. Une case vide, elle, ne prouve rien — ni le refus, ni la question posée.

C’est cette dernière ligne qui décide de la forme d’un recueil informatisé : il faut pouvoir distinguer « le client n’en veut pas », « ça ne le concerne pas », « il veut d’abord savoir combien ça coûte » et « la question n’a pas été posée ». Quatre états différents, que la plupart des formulaires écrasent en une seule case à cocher.

Le recueil s’ouvre depuis la fiche d’un client ou d’un prospect, pour un produit à la fois — santé, auto, habitation, prévoyance, emprunteur, professionnel ou décennale. Il porte une référence communicable de la forme REC-AAMM-XXXXXX, et se remplit en douze rubriques numérotées :

• 1 — Contexte de la démarche : comment le recueil a été fait (téléphone, rendez-vous, visioconférence, formulaire du site, e-mail, courrier) et pourquoi le client vient aujourd’hui (première souscription, prix, garanties insuffisantes, qualité de service, changement de situation, fin d’un contrat collectif, échéance).
• 2 et 3 — Identité du souscripteur et composition du foyer : une ligne par personne, son lien, sa date de naissance, et si elle doit être assurée — avec le motif quand elle ne l’est pas.
• 4 — Situation sociale et professionnelle : régime obligatoire, régime local Alsace-Moselle en plus du régime de base et non à sa place, statut professionnel, rattachement à la sécurité sociale, complémentaire santé solidaire, mesure de protection juridique.
• 5 — Couverture actuelle : une ligne par contrat en place, avec la compagnie, la formule, la cotisation et sa périodicité, la franchise, l’échéance, le motif d’insatisfaction, et s’il souhaite résilier — puis, séparément, ce que ce contrat couvre réellement poste par poste.
• 6 — Besoins par poste : pour chaque garantie, ce que le client en veut (souhaitée, refusée, à chiffrer), l’importance qu’il y attache (essentiel, important, secondaire, sans objet), le niveau visé (minimum, moyen, renforcé, maximum) et son besoin précis en toutes lettres.
• 7 à 10 — Services attendus, budget et contraintes, besoins connexes, puis les exigences et déclarations libres du client, dans ses mots.
• 11 et 12 — Pièces reçues et pièces à fournir, puis la validation, qui affiche nommément ce qui manque encore.

Un classement des critères d’arbitrage s’ajoute au-dessus des garanties : le prix, l’étendue des garanties, la réactivité de l’assureur, la notoriété de la compagnie, le délai d’obtention de l’attestation — rangés par le client lui-même. C’est ce qui départagera deux offres proches, et ce qu’un document de conseil doit pouvoir restituer.

Le référentiel de garanties est aujourd’hui servi pour la santé et pour la décennale. Sur les autres produits, les rubriques communes fonctionnent, mais la grille poste par poste n’est pas encore publiée : nous préférons le dire plutôt que d’afficher une liste qui donnerait le change en démonstration.

Une précision de plus, dans le même esprit : à l’écran, la grille poste par poste de la rubrique 6 suit le produit du recueil — treize garanties pour une décennale, de la responsabilité civile décennale aux dommages immatériels. La fiche de recueil imprimée, elle, reprend encore aujourd’hui les postes de la santé : sur une décennale, la rubrique « besoins exprimés, poste par poste » du document reste vide, et le document l’omet. Le vocabulaire existe donc, et il décrit déjà le contrat en place ; c’est le document qui n’a pas encore rattrapé l’écran.

Un recueil pré-rempli va vite, et c’est exactement là que se glisse une déclaration que le client n’a jamais faite. Chaque champ porte donc sa provenance, affichée à côté de lui : déclaré par le client, déclaré sur le site, repris de la fiche prospect, repris du profil de devis, déduit d’une autre saisie, proposé par un agent puis confirmé par vous, ou proposé par l’IA et pas encore repris.

Cette dernière provenance a une conséquence dure : un champ encore marqué « proposé par l’IA — à confirmer » empêche la validation du recueil, et le message nomme les champs concernés. Une machine ne déclare pas les besoins d’un client à sa place.

Même logique sur les booléens : tant que la question n’a pas été posée, le champ reste vide. Il ne vaut pas « non ». Un formulaire qui répond « non » à une question jamais posée transforme un silence en déclaration du client — et c’est le genre de détail qui se retourne contre un cabinet.

Un recueil vit en quatre états : brouillon, validé, remplacé, archivé. La validation le gèle — elle enregistre la date, l’heure et l’utilisateur qui a validé — et le recueil n’est alors plus modifiable. Une personne ne peut avoir qu’un seul recueil validé par produit à un instant donné : le second est refusé, en nommant celui qui fait foi.

Quand les besoins changent, on ne réécrit pas : une version suivante est créée, avec un motif obligatoire qui dit ce qui a changé. La version précédente passe à « remplacé » et reste consultable, avec tout ce qu’elle portait — y compris ce que le contrat en place couvrait au moment où il a été lu. C’est la chaîne qui prouve le suivi du conseil dans le temps, pas le dernier état.

Un archivage est possible, mais il demande lui aussi un motif, et il écrit une note datée dans l’historique du client ou du prospect : « ce recueil ne fait plus foi », suivi du motif. Personne ne peut faire disparaître silencieusement une pièce du dossier.

Enfin, un écran de suivi liste les recueils de tout le cabinet, brouillons d’abord, 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.

La fiche de recueil des besoins se génère depuis les données saisies, en neuf rubriques : le client, le contexte de la démarche, la composition du foyer, les besoins exprimés poste par poste, ce qui compte le plus pour lui, la couverture actuelle, le budget, ses mots à lui, et l’engagement du client — lequel rappelle les conséquences d’une fausse déclaration, articles L. 113-8 et L. 113-9 du Code des assurances. Elle part ensuite à la signature électronique, ou s’imprime.

Un point mérite d’être dit, parce qu’il est presque toujours confondu : produire un document n’est pas le remettre. Les deux faits sont donc écrits séparément — l’émission au moment où le document est généré, la remise au moment où il part — avec le canal utilisé : signature électronique, e-mail, remise en main propre, courrier, ou signature sur l’extranet de la compagnie. Et la date de la première remise n’est jamais réécrite : une relance n’est pas une nouvelle remise, c’est l’antériorité qui compte.

Le bilan de conseil se pré-remplit ensuite à partir du recueil, dans le même mouvement. Avec une règle qui vaut d’être connue : un champ non saisi rend une ligne vide, jamais un « Non » de confort. Un document qui affiche « Non » à une question jamais posée est plus dangereux qu’un document incomplet.

Le recueil n’est pas un formulaire de plus à remplir après la vente : il vient avant. Il alimente le profil de devis, les tarifs obtenus reviennent dans la fiche, et l’analyse comparative puis le devoir de conseil se construisent sur ce qui a été déclaré — pas sur ce qu’on se rappelle en rédigeant.

Cette séquence est racontée heure par heure, avec le reste de la journée, dans une journée type dans un cabinet de courtage — scène de 14 h. Et le mécanisme de tarification est décrit sur la page des devis multi-compagnies.

Il ne décide pas de l’adéquation entre un contrat et des besoins, et il ne rend personne conforme. L’analyse comparative et le document de conseil sont des propositions : vous les corrigez, vous les validez, et la recommandation reste votre acte professionnel.

Il ne remplit pas non plus le recueil à votre place à partir d’un simple document : ce qu’un agent extrait arrive marqué comme proposé, et bloque la validation tant que personne ne l’a repris. C’est plus lent qu’un pré-remplissage aveugle, et c’est voulu.

Éléments relevés dans la version en production d’ACTUAL DATA le 8 septembre 2026. Le référentiel de garanties poste par poste est servi pour la santé et la décennale ; la grille de saisie affiche celui du produit, le document imprimé reprend encore les postes de la santé ; les autres produits utilisent les rubriques communes. Cette page décrit un logiciel et présente un cadre réglementaire ; elle ne constitue pas une consultation juridique sur votre situation.