Tickets de modification

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, lorsqu’un support est détenu par plusieurs personnes, par exemple un compte joint avec deux cotitulaires, la fiche permet bien de renseigner plusieurs détenteurs. Dans l’exemple affiché, le compte est détenu par Tristan LANGLOIS et Sarah PABOIS. En revanche, dans la brique récapitulative affichée en haut puis une fois le support replié, seul le premier cotitulaire apparaît.

Attendu : La brique récapitulative doit reprendre l’ensemble des cotitulaires renseignés pour le support. Dans l’exemple concerné, l’affichage devrait donc indiquer : Compte courant Tristan LANGLOIS & Sarah PABOIS 400 € Le même principe doit s’appliquer dès qu’un support comporte plusieurs détenteurs, quel que soit le mode de détention concerné.

Intention : Faire en sorte que la brique synthétique reflète fidèlement la détention réelle du support et permette d’identifier immédiatement toutes les personnes concernées.

Gêne : L’affichage d’un seul cotitulaire donne une information incomplète et peut laisser penser que le support appartient uniquement à cette personne. Cela crée une incohérence entre les données renseignées dans la fiche et leur restitution synthétique.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, dans la rubrique Liquidités et comptes réglementés, le champ « Détenteur » permet actuellement de sélectionner notamment : Tristan LANGLOIS ; Sarah PABOIS ; « Un tiers · à préciser » ; « Une personne morale · à préciser ». Deux limites apparaissent : Lorsque « Un tiers · à préciser » ou « Une personne morale · à préciser » est sélectionné, aucun champ complémentaire exploitable ne permet de renseigner l’identité du tiers ou la dénomination de la personne morale concernée. Les enfants déjà connus dans le dossier ne sont pas proposés directement parmi les détenteurs possibles. Par exemple, si Rose LANGLOIS est déjà renseignée dans la composition familiale, elle devrait pouvoir être sélectionnée au même titre que Tristan LANGLOIS ou Sarah PABOIS.

Attendu : Le fonctionnement du champ « Détenteur » devrait être complété de la manière suivante : les membres du foyer ou de la famille déjà connus dans le dossier et susceptibles d’être détenteurs, notamment les enfants renseignés, doivent être proposés directement dans la liste ; si « Un tiers · à préciser » est sélectionné, un champ complémentaire doit apparaître afin de renseigner l’identité du tiers ; si « Une personne morale · à préciser » est sélectionnée, un champ complémentaire doit apparaître afin de renseigner la dénomination de la personne morale ; ces informations doivent ensuite être enregistrées et reprises dans la brique synthétique du support afin que le détenteur soit clairement identifiable.

Intention : Éviter de conserver des supports avec un détenteur générique et exploiter les informations déjà connues dans le dossier plutôt que de contraindre le prospect à utiliser systématiquement une catégorie « à préciser ».

Gêne : En l’état, un support peut rester rattaché à « Un tiers · à préciser » ou « Une personne morale · à préciser » sans qu’il soit possible de savoir précisément qui en est détenteur. Cela réduit la qualité de la donnée patrimoniale et oblige à compléter cette information ultérieurement. Par ailleurs, ne pas proposer les enfants déjà renseignés dans le dossier crée une saisie inutilement imprécise alors que leur identité est déjà connue.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 12 sur 22 – Immobilier indirect du DCI complet, lorsqu’un support est renseigné puis affiché sous forme de brique, l’intitulé reprend essentiellement le type de support. Par exemple, une SCPI apparaît simplement sous l’intitulé « SCPI », avec le détenteur en dessous et la valorisation à droite. Lorsque le prospect détient plusieurs supports de même nature, il peut donc se retrouver avec plusieurs briques intitulées « SCPI » sans pouvoir identifier immédiatement laquelle correspond à quel investissement.

Attendu : Conserver les informations actuellement utiles dans la brique, notamment : le type de support ; le détenteur ; la valorisation totale. Ajouter en complément une information permettant d’identifier précisément le support concerné, à partir des données déjà renseignées dans sa fiche, par exemple le nom du support et/ou la société de gestion. Exemple d’affichage : SCPI – Corum Tristan LANGLOIS 10 000 € L’objectif est que plusieurs supports de même type puissent être distingués immédiatement sans devoir ouvrir chaque brique.

Intention : Permettre au prospect et à l’ingénieur patrimonial d’identifier rapidement chaque investissement immobilier indirect, notamment lorsqu’un même foyer détient plusieurs SCPI ou plusieurs supports de même nature.

Gêne : Avec plusieurs briques affichant uniquement « SCPI », le type de support ne suffit plus à les différencier. Il faut alors se souvenir des valorisations ou rouvrir les différentes fiches pour retrouver l’investissement recherché, ce qui dégrade la lisibilité du patrimoine renseigné.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 12 sur 22 du DCI complet, lors de la création ou de la modification d’un actif d’immobilier indirect (par exemple une SCPI), la question « Un prêt est-il associé à ce bien ? » propose les réponses Oui / Non. Lorsque le prospect sélectionne « Oui », la brique de l’actif qu’il est en train de renseigner se replie automatiquement, alors même que la saisie de cet actif n’est pas nécessairement terminée.

Attendu : La sélection de « Oui » doit uniquement : enregistrer la réponse ; créer automatiquement la fiche d’emprunt associée dans la section « Emprunts et dettes » ; conserver le lien entre cet emprunt et l’actif concerné. La brique de l’actif immobilier indirect doit rester ouverte afin que le prospect puisse poursuivre normalement sa saisie. La sélection de « Non » ne doit pas non plus provoquer de repli automatique de la brique.

Intention : Faire en sorte que cette question pilote uniquement la création éventuelle d’un emprunt associé, sans interrompre le parcours de saisie de l’actif en cours.

Gêne : Le repli automatique donne l’impression que la saisie de l’actif est terminée alors que d’autres informations peuvent encore devoir être complétées. Cela interrompt inutilement le parcours et oblige le prospect à rouvrir la brique pour continuer.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 18 sur 22 – Emprunts et dettes du DCI complet, les numéros affichés dans les cercles à gauche des briques ne correspondent pas au nombre réel d’emprunts présents sur la page. Dans l’exemple affiché, il n’y a que deux crédits, mais ils portent les numéros 3 et 4.

Attendu : La numérotation des emprunts et dettes doit commencer à 1 et suivre l’ordre des éléments présents dans la rubrique. Dans le cas affiché, les deux crédits devraient donc apparaître comme : 1 – Prêt immobilier (résidence principale) 2 – Prêt immobilier (résidence principale) La numérotation doit également se recalculer si un emprunt ou une dette est ajouté ou supprimé.

Intention : Faire en sorte que la numérotation serve réellement de repère visuel et corresponde aux éléments effectivement présents dans la rubrique.

Gêne : Une numérotation commençant à 3 alors que seuls deux crédits sont affichés donne l’impression que des éléments sont manquants ou masqués. Cela crée une incohérence visuelle et peut semer le doute chez le prospect.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 20 sur 22 – Vos objectifs détaillés, le prospect peut renseigner plusieurs informations pour chaque objectif : type d’objectif, importance, échéances, contexte, montant cible, bénéficiaires concernés, etc. En revanche, chaque objectif ne dispose pas d’un bouton d’enregistrement visible. Le prospect n’a donc pas de confirmation claire que les informations qu’il vient de renseigner ont bien été sauvegardées avant de poursuivre. Par ailleurs, les objectifs restent entièrement déployés après leur saisie, ce qui alourdit rapidement la page lorsqu’il y en a plusieurs.

Attendu : Ajouter, en bas à droite de chaque objectif, un bouton permettant de l’enregistrer explicitement. Une fois l’objectif enregistré : le prospect doit avoir une confirmation visuelle claire de son enregistrement ; l’objectif doit automatiquement se replier sous forme de brique synthétique ; cette brique doit permettre d’identifier immédiatement l’objectif, notamment grâce à son titre ; le prospect doit pouvoir rouvrir la brique pour modifier l’objectif si nécessaire. Par exemple, après enregistrement, une brique pourrait simplement afficher : Projet de remontée sur Nantes ou : Investir pour générer des revenus En cas de modification ultérieure, le prospect doit pouvoir enregistrer à nouveau les changements avant que la brique ne se replie.

Intention : Donner au prospect un repère clair confirmant que chaque objectif a bien été enregistré et améliorer la lisibilité de la page lorsqu’il renseigne plusieurs objectifs.

Gêne : En l’état, le prospect peut hésiter à passer à l’étape suivante, faute de confirmation visible que sa saisie a bien été conservée. Lorsque plusieurs objectifs sont renseignés, leur affichage entièrement déployé rend également la page longue et moins facile à relire.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 21 sur 22 du DCI complet, l’encart « Prochaine étape – Ce que deviennent vos réponses » présente actuellement le texte suivant : « Les éléments que vous venez de renseigner vont être consolidés et analysés par votre ingénieur patrimonial. Ils serviront de support à votre prochain entretien et permettront de préparer l’analyse de votre situation. Votre patrimoine consolidé et vos ratios financiers vous seront présentés à cette occasion : ils tiennent compte des quote-parts de détention, des passifs et du barème fiscal de l’article 669 du CGI pour les biens démembrés, que seul votre ingénieur patrimonial croise. Vous pourrez compléter ou préciser certaines informations avec lui lors de cet entretien. Vous pouvez maintenant poursuivre vers la validation et la signature de votre questionnaire. » Le premier paragraphe est pertinent. En revanche, le deuxième paragraphe est trop affirmatif et trop technique : il indique notamment que le patrimoine consolidé et les ratios financiers seront nécessairement présentés lors du prochain entretien, ce qui ne correspond pas systématiquement au déroulement de cet échange. La prochaine étape est avant tout un entretien initial avec l’ingénieur patrimonial, destiné à échanger avec le prospect sur sa situation patrimoniale et ses besoins, à préciser les informations recueillies lorsque cela est nécessaire et à apprécier l’accompagnement qui pourrait être pertinent.

Attendu : Conserver une formulation simple, exacte et rassurante, sans annoncer des éléments qui ne seront pas nécessairement présentés lors de l’entretien. Proposition de texte : « Les éléments que vous venez de renseigner vont être consolidés et analysés par votre ingénieur patrimonial. Ils serviront de support à votre prochain entretien et permettront de préparer l’analyse de votre situation. Les informations communiquées seront abordées à cette occasion et pourront être complétées ou précisées avec votre ingénieur patrimonial si nécessaire. Vous pouvez maintenant poursuivre vers la validation et la signature de votre questionnaire. » Le passage relatif aux ratios financiers, quote-parts de détention, passifs et barème fiscal de l’article 669 du CGI doit être supprimé de cet écran.

Intention : Présenter au prospect de manière fidèle et compréhensible ce qui va réellement se passer après la saisie du DCI complet, sans entrer prématurément dans des éléments techniques ni annoncer un contenu d’entretien qui n’est pas systématique.

Gêne : La rédaction actuelle peut créer une attente erronée sur le contenu du prochain entretien et introduit des notions techniques qui n’apportent rien à cette étape du parcours. L’objectif de cet écran doit rester simple : expliquer que les informations seront analysées, reprises avec l’ingénieur patrimonial et précisées si nécessaire.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 21 sur 22 du DCI complet, sous le titre « Vos informations ont bien été recueillies », la phrase suivante est affichée : « Ce qui suit vous explique ce qu'elles vont devenir. Rien ne reste à saisir sur cette page. » Cette phrase n’apporte pas d’information utile au prospect, alourdit visuellement la page et fait doublon avec l’encart situé immédiatement en dessous.

Attendu : Supprimer entièrement cette phrase. La page peut directement afficher : « Vos informations ont bien été recueillies » puis l’encart : « Prochaine étape – Ce que deviennent vos réponses »

Intention : Alléger cette étape de transition et rendre la lecture plus fluide, sans ajouter de texte intermédiaire qui ne contribue pas à la compréhension du parcours.

Gêne : La formulation actuelle est peu naturelle et redondante avec le contenu de l’encart suivant. Elle nuit à la simplicité de la page alors qu’à ce stade, le prospect a surtout besoin de comprendre que sa saisie est terminée et ce qui va se passer ensuite.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 17 sur 22 du DCI complet, la page regroupe deux rubriques distinctes : Couverture prévoyance et Mutuelle santé. Pourtant, le titre principal affiché en haut de page est uniquement « Prévoyance ».

Attendu : Le titre principal de la page doit être remplacé par : « Mutuelle et prévoyance » afin de refléter les deux catégories effectivement traitées sur cette étape.

Intention : Faire correspondre l’intitulé de l’étape à son contenu réel et rendre le parcours plus compréhensible pour le prospect.

Gêne : Le titre actuel laisse penser que l’étape concerne uniquement la prévoyance alors qu’elle permet également de renseigner les contrats de mutuelle santé.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : Dans la rubrique Mutuelle santé, lors de l’ajout ou de la modification d’un contrat, le prospect doit actuellement renseigner une « Cotisation mensuelle ». Ce montant est ensuite également affiché dans la brique repliée du contrat, à droite de l’intitulé. Cette information paraît trop détaillée pour le DCI complet à ce stade du parcours, alors que le prospect est encore dans une phase de collecte initiale et que le montant de la cotisation pourra être récupéré et vérifié ultérieurement lors de l’analyse documentaire du contrat. Par ailleurs, l’affichage isolé d’un montant dans la brique repliée donne visuellement l’impression qu’il s’agit d’une valorisation ou d’un solde, ce qui n’est pas adapté à un contrat de mutuelle.

Attendu : Supprimer le champ « Cotisation mensuelle » du formulaire de création et de modification d’un contrat de mutuelle dans le DCI complet. Le montant de cotisation ne doit également plus apparaître dans la brique repliée du contrat. La brique repliée doit conserver uniquement les informations réellement utiles pour identifier le contrat, notamment l’organisme et l’assuré, ainsi que toute autre information d’identification déjà retenue comme pertinente.

Intention : Alléger le DCI complet en ne demandant au prospect que les informations nécessaires à l’identification de ses contrats, puis réserver les données contractuelles plus précises à l’analyse documentaire.

Gêne : Cette donnée ajoute une saisie qui ne paraît pas nécessaire à ce stade et qui pourra être obtenue de manière plus fiable à partir des pièces du contrat. Son affichage dans la brique repliée est également ambigu et peu pertinent pour identifier une mutuelle.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la section Budget de la configuration de la collecte documentaire, la question « Une dépense importante est-elle prévue ? » fonctionne de manière conditionnelle : les questions à poser au client évoluent selon la réponse apportée. En revanche, même lorsqu’une dépense importante est confirmée, aucune demande de document complémentaire n’est ajoutée pour permettre au client de transmettre un justificatif ou tout document apportant des informations sur cette dépense.

Attendu : Lorsque la réponse à la question « Une dépense importante est-elle prévue ? » est « Oui », que cette réponse soit renseignée par l’ingénieur patrimonial ou par le client, la collecte doit faire apparaître une demande documentaire complémentaire permettant au client de déposer tout document utile relatif à cette dépense. La demande doit rester suffisamment générique pour s’adapter à la nature de la dépense concernée. Lorsque la réponse est « Non », cette demande documentaire ne doit pas apparaître.

Intention : Faire en sorte que la logique conditionnelle appliquée aux questions de qualification pilote également les documents à collecter lorsque l’existence d’une dépense importante est confirmée.

Gêne : En l’état, le client peut déclarer une dépense importante sans pouvoir transmettre directement les documents permettant d’en préciser la nature, le montant, l’échéance ou les modalités. L’ingénieur patrimonial risque donc de devoir réclamer ces éléments ultérieurement en dehors du parcours de collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la section Budget de la configuration de la collecte documentaire, la question « Une rentrée d’argent est-elle prévue ? » fonctionne désormais de manière conditionnelle : les éléments à demander au client évoluent selon la réponse À confirmer / Oui / Non. En revanche, quelle que soit la réponse apportée, aucune demande de document complémentaire n’est générée pour permettre de documenter une rentrée d’argent à venir.

Attendu : Lorsque la réponse à la question « Une rentrée d’argent est-elle prévue ? » est « Oui », que cette réponse soit renseignée par l’ingénieur patrimonial ou ultérieurement par le client, la collecte doit permettre de demander un document utile relatif à cette rentrée d’argent à venir. Il conviendrait de prévoir une demande documentaire suffisamment générique pour permettre au client de transmettre le justificatif adapté à la nature de la rentrée d’argent concernée. Lorsque la réponse est « Non », cette demande documentaire ne doit pas apparaître.

Intention : Permettre à la logique conditionnelle de ne pas seulement adapter les questions posées au client, mais également les documents demandés lorsque l’existence d’une rentrée d’argent future est confirmée.

Gêne : En l’état, une rentrée d’argent peut être déclarée sans qu’aucune pièce permettant d’en préciser ou d’en justifier la nature, le montant ou les modalités ne soit collectée. L’ingénieur patrimonial risque donc de devoir demander ce document ultérieurement, en dehors du parcours de collecte prévu.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Lorsqu’une section de la collecte documentaire a été marquée « Prête » par l’ingénieur patrimonial, une modification peut ensuite être réalisée dans les questions de qualification de cette section. Dans cette situation, le statut « Prête » ne permet plus d’identifier que la configuration de la section a été modifiée depuis sa dernière validation.

Attendu : Dès qu’une modification est effectuée sur une question de qualification d’une section déjà marquée « Prête », la section doit automatiquement repasser en statut non prête. Le bouton affiché à droite de la barre de la section doit alors redevenir « Marquer prête ». Cette réinitialisation doit intervenir pour toute modification d’une question de qualification de la section, qu’elle soit volontaire ou accidentelle.

Intention : Faire en sorte que le statut « Prête » corresponde toujours à la dernière configuration effectivement validée par l’ingénieur patrimonial.

Gêne : Sans réinitialisation automatique, une section peut apparaître comme prête alors que son paramétrage a été modifié après validation. Cela crée un risque de poursuivre la collecte documentaire sur la base d’une configuration qui n’a pas été revalidée.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : La section 6 – Actifs financiers de la configuration de la collecte documentaire fonctionne actuellement comme un bloc global regroupant de nombreuses catégories de placements : comptes bancaires, livrets, comptes à terme, assurance-vie, capitalisation, PEA, compte-titres, retraite, épargne salariale, private equity, financement participatif, obligations, produits structurés, cryptoactifs, Girardin industriel, etc. Cette organisation devient rapidement difficile à exploiter dès que le foyer possède plusieurs supports. Une réponse globale telle que : « Le foyer détient-il une assurance-vie ? → Oui » ne permet pas de savoir s’il existe un ou plusieurs contrats, à qui ils appartiennent, quelles sont leurs caractéristiques ni quels justificatifs doivent être demandés pour chacun. Surtout, les informations utiles et les documents nécessaires diffèrent fortement selon le support. Il n’est par exemple pas pertinent de demander les mêmes informations pour un compte courant et une assurance-vie. Le chantier doit donc transformer cette section selon la logique suivante : 1 support financier = 1 bloc identifiable = 1 détenteur ou ensemble de détenteurs = 1 qualification adaptée au produit = 1 collecte documentaire propre au support. Les actifs déjà renseignés dans le DCI complet doivent être précréés automatiquement. L’ingénieur patrimonial doit ensuite pouvoir vérifier, compléter, ajouter ou supprimer les supports avant l’envoi de la collecte. Il faut également distinguer les actifs financiers détenus personnellement par les clients de ceux qui sont détenus au sein de leurs sociétés, tout en conservant des liens entre les différentes sections du dossier.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : La section 4 – Patrimoine professionnel de la configuration de la collecte documentaire fonctionne actuellement comme un bloc global dans lequel sont mélangées les questions relatives aux différentes activités et sociétés du foyer ainsi qu’un très grand nombre de documents potentiellement demandés. Dans un dossier comportant plusieurs sociétés, cette organisation devient rapidement difficilement exploitable. Un client peut par exemple détenir : une holding ; une ou plusieurs sociétés d’exploitation ; plusieurs filiales ; une société civile ; des participations minoritaires dans d’autres structures ; différentes sociétés sans lien capitalistique entre elles. Chaque société peut pourtant avoir des caractéristiques totalement différentes : associés, pourcentages de détention, pacte d’associés, convention de trésorerie, comptes annuels, assurances professionnelles, protection sociale, prévoyance, mutuelle, épargne salariale, dispositifs retraite, projets de cession ou de transmission, etc. Le fonctionnement attendu doit donc devenir : 1 société = 1 bloc identifiable = 1 qualification propre = 1 ensemble de questions et de documents rattachés à cette société. Comme pour l’immobilier, les sociétés déjà renseignées dans le DCI complet ou connues du dossier doivent être précréées automatiquement lors de l’ouverture de la configuration de la collecte. L’ingénieur patrimonial complète ensuite la configuration société par société et peut créer les structures manquantes.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : La section 5 – Immobilier de la configuration de la collecte documentaire fonctionne actuellement comme un bloc unique regroupant un très grand nombre de questions et de documents. Dans ce même bloc sont mélangés : le logement d’usage ; les éventuelles résidences secondaires ; les biens immobiliers locatifs ; plusieurs biens locatifs pouvant avoir des caractéristiques différentes ; les biens détenus directement ou via une société ; les situations d’indivision ; les travaux ; les financements ; les projets de vente ; les parts de SCPI ; et les documents associés à toutes ces situations. Cette organisation devient difficilement exploitable dès qu’un foyer possède plusieurs actifs immobiliers. Une réponse globale telle que : « Le foyer détient-il de l’immobilier locatif ? → Oui » ne permet pas de savoir s’il existe un, trois ou cinq biens, ni de déterminer quel bien est concerné par une location, des travaux, un crédit, une vente envisagée, une indivision ou un document demandé. Le chantier doit donc transformer la section Immobilier en une logique : 1 actif immobilier = 1 bloc identifiable = 1 configuration propre = 1 ensemble de questions et de documents rattachés à cet actif. Les informations déjà connues grâce au DCI complet, à l’entretien initial ou au dossier existant doivent servir à préconstituer les blocs lorsque cela est possible. L’ingénieur patrimonial doit ensuite pouvoir compléter, ajouter, modifier ou supprimer les blocs avant d’envoyer la collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section « Identité et situation familiale », lorsque l’ingénieur patrimonial ou le client indique qu’un enfant du foyer est décédé, le moteur conditionnel déclenche actuellement plusieurs éléments, dont : l’identification de l’enfant concerné ; la question permettant de savoir si cet enfant avait lui-même des descendants ; le cas échéant, l’identification de ces descendants ; mais également une demande documentaire : « Acte de décès de [l’enfant] ». Les premières questions sont pertinentes pour comprendre la situation familiale et identifier d’éventuels descendants susceptibles d’être concernés par l’analyse successorale. En revanche, la demande automatique de l’acte de décès de l’enfant paraît disproportionnée à ce stade. Elle peut être particulièrement sensible pour le client et l’oblige à rechercher puis transmettre un document douloureux, alors qu’il n’est pas nécessaire à la collecte patrimoniale standard telle qu’elle est conçue ici.

Attendu : Conserver la logique conditionnelle permettant, en cas de réponse Oui à : « Un enfant est-il décédé ? » de demander : quel enfant est concerné, en reprenant si possible les enfants déjà identifiés dans le dossier ; si cet enfant avait lui-même des descendants ; si oui, l’identité des descendants concernés. En revanche, ne plus ajouter automatiquement l’acte de décès de l’enfant dans « Documents à demander au client ». La logique attendue devient donc : Enfant décédé = information familiale à approfondir, mais pas de justificatif de décès demandé automatiquement. Si, dans un dossier particulier, l’ingénieur patrimonial estime ultérieurement qu’un tel document est réellement nécessaire, il doit conserver la possibilité de l’ajouter manuellement à la collecte documentaire.

Intention : Recueillir les informations réellement utiles à la compréhension de la situation familiale et successorale tout en évitant de demander automatiquement au client un document particulièrement sensible lorsqu’il n’est pas nécessaire à l’analyse patrimoniale courante.

Gêne : La demande automatique de l’acte de décès peut : raviver inutilement une situation douloureuse pour le client ; alourdir la collecte avec une pièce qui n’est pas nécessaire dans la majorité des dossiers ; donner l’impression que le client doit justifier systématiquement le décès d’un enfant ; détourner l’attention des informations réellement utiles ici : identité de l’enfant concerné et existence éventuelle de descendants.

https://app.astraeos.fr/parcours/dci-complet?prospect=<slug>

Problème : Depuis la correction du signalement 545 sur la reprise des brouillons, le rendu du serveur fait autorité sur la structure du questionnaire : une question ajoutée, un intitulé corrigé ou une option nouvelle parviennent bien au prospect qui avait déjà commencé. Les fiches d'actifs font exception. Biens, emprunts, contrats, supports financiers : ces fiches n'existent dans aucun rendu du serveur, elles sont créées à la volée pendant la saisie. À la reprise, elles sont déplacées telles quelles depuis le brouillon, avec leur markup d'origine. Un prospect qui a déjà déclaré trois emprunts garde donc les anciens intitulés sur ces trois fiches. La correction du signalement 480 (« Durée totale » devient « Durée totale (en mois) ») et l'allègement du signalement 481 ne s'appliquent qu'aux fiches ajoutées après la livraison. Deux emprunts du même dossier peuvent afficher deux versions différentes du même formulaire. Le choix de déplacer les fiches sans y toucher était délibéré : les recomposer risquait de perdre la saisie du prospect. Il fallait d'abord une reprise par les valeurs éprouvée ; elle l'est désormais.

Attendu : Une fiche d'actif reprise doit être reconstruite à partir du questionnaire courant, puis recevoir les réponses que le prospect y avait mises. 1. À la reprise, chaque fiche est recréée par le générateur en vigueur pour son type (liquidité, support d'investissement, assurance-vie, retraite, prévoyance, mutuelle, emprunt, bien d'usage, bien locatif, société, actif atypique, événement, donation, projet, dispositif). 2. Les réponses du prospect sont ensuite reportées dans la fiche reconstruite, retrouvées par leur libellé, comme pour le reste du questionnaire. 3. Le nombre de fiches, leur ordre et leurs identifiants sont conservés : les liaisons prêt / bien qui s'appuient sur ces identifiants doivent continuer de fonctionner. 4. Une réponse dont le champ n'existe plus dans la fiche reconstruite est signalée, jamais perdue en silence. 5. Aucune fiche ne doit disparaître : le garde-fou du signalement 545, qui refuse d'écrire un brouillon plus pauvre, reste en vigueur pendant l'opération. 6. Éprouvé sur un brouillon réel portant plusieurs fiches de types différents : intitulés à jour, valeurs intactes, liaisons intactes.

Intention : Qu'une correction livrée atteigne tout le monde, y compris ce qui a déjà été saisi. Sans cela, la moitié du bénéfice du signalement 545 est perdue. --- État au 13/08, après une première tentative --- La reconstruction fonctionne : fiches recréées par leur générateur, intitulés à jour (« Durée restante (en mois) » présent sur les fiches reprises), nombre de fiches conservé (23), identifiants conservés (pret-1, pret-2), liaisons prêt / bien intactes. Deux pièges rencontrés, tous deux corrigés dans la tentative : 1. Une liste sans générateur (fatcaList, ppeList) passait pour reconstruite par coïncidence de comptage, et perdait le contenu du brouillon. Le générateur doit déclarer explicitement qu'il a agi. 2. Recréer une fiche de bien d'usage rejoue la création automatique de son emprunt associé (signalement 479), qui s'ajoute à celui déjà repris. L'automatisme doit être neutralisé pendant la reprise. Le point à trancher : la reconstruction fait tomber les réponses de 203 à 183 champs remplis sur le brouillon témoin. Les 20 réponses perdues portent sur des champs que les signalements 481 et 503 ont volontairement supprimés (durée totale de l'emprunt, description / date / montant de chaque opération de travaux, entreprise par opération). Ce ne sont donc pas des réponses égarées mais des réponses devenues sans destination, et l'écran le signale (« Certaines réponses n'ont pas pu être retrouvées »). La tentative n'a pas été livrée : elle demande d'assumer cette perte, ce qui est une décision produit, pas technique. Le travail est reproductible à l'identique.

Gêne : Le prospect voit deux versions du même formulaire dans un même dossier. L'ingénieur reçoit des durées d'emprunt sans unité sur les fiches anciennes et en mois sur les nouvelles, sans moyen de savoir laquelle est laquelle.

https://app.astraeos.fr/parcours/dci-complet?prospect=<slug>

Problème : Le questionnaire du DCI complet enregistre automatiquement son brouillon, en local et sur le serveur. L'écriture ne dépend d'aucune action de saisie : elle se déclenche dès que l'empreinte du questionnaire change, or la simple ouverture du lien recompose cette empreinte (reprise du brouillon, navigation entre les étapes, réactions des champs qui en commandent d'autres). Conséquence : ouvrir le lien nominatif d'un prospect pour regarder où il en est réécrit son brouillon serveur. La copie enregistrée devient celle de la personne qui a consulté, pas celle du prospect. Le problème est resté invisible parce qu'aucun appel réseau n'apparaît dans le code client : l'écriture passe par une action serveur, qu'une recherche de « fetch » ne trouve pas. Constaté en conditions réelles le 12 août : le brouillon du prospect de démonstration a été écrasé pendant une session de vérification. La copie de référence dans dci_submissions comptait 166 916 caractères et 23 cartes d'actifs ; le brouillon réécrit n'en comptait plus que 69 879 et aucune carte. Aucune donnée n'a été perdue parce qu'une copie plus complète existait ailleurs, mais rien ne le garantissait.

Attendu : Consulter ne doit jamais écrire. 1. Une ouverture du lien qui ne s'accompagne d'aucune saisie du prospect ne doit produire aucun enregistrement, ni local ni serveur. La reprise du brouillon, la navigation entre les étapes et les réactions en chaîne des champs ne sont pas des saisies. 2. L'enregistrement ne doit partir que sur une action réelle du prospect : une frappe, un choix dans un menu, une bascule oui/non, l'ajout ou la suppression d'une carte. 3. Un brouillon plus riche que celui qui s'apprête à être écrit ne doit jamais être remplacé en silence. Si l'état à enregistrer est plus pauvre que celui déjà en base, l'écriture est refusée et la situation est signalée. 4. Cette règle vaut pour toutes les étapes et pour tous les parcours qui enregistrent un brouillon, pas seulement pour le DCI complet : le DCI simplifié et les questionnaires de qualification suivent la même mécanique. 5. Le comportement doit être éprouvé par un test qui ouvre un parcours porteur d'un brouillon, ne touche à rien, et vérifie qu'aucune écriture n'a eu lieu.

Intention : Permettre à l'équipe de consulter le dossier d'un prospect sans l'altérer. Aujourd'hui, regarder pour comprendre où en est un client abîme ce qu'il a saisi.

Gêne : Un ingénieur qui ouvre le lien d'un prospect pour préparer son entretien détruit une partie de la saisie de ce prospect, sans le savoir et sans qu'aucun message ne l'en avertisse. Le prospect, lui, retrouve un questionnaire amputé à sa prochaine visite.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : La configuration de la collecte documentaire comporte actuellement 11 sections, la dernière étant « Informations complémentaires ». Il manque une rubrique permettant d’identifier les professionnels qui accompagnent déjà habituellement le client ou le foyer dans la gestion de ses affaires patrimoniales, juridiques, fiscales ou comptables. Il serait utile de savoir notamment si le foyer travaille déjà avec : un notaire ; un expert-comptable ou cabinet d’expertise comptable ; un avocat ou cabinet d’avocats ; éventuellement un autre professionnel ou conseil en lien avec son patrimoine. Il est également nécessaire de savoir si le client autorise ASTRAEOS à prendre contact avec ces professionnels dans le cadre de la réalisation de l’étude patrimoniale.

Attendu : Créer, après « Informations complémentaires », une nouvelle section : 12 – Partenaires et conseils habituels Cette section doit permettre d’identifier les professionnels avec lesquels le client travaille déjà. Questions proposées : Travaillez-vous habituellement avec un notaire ? Oui / Non Travaillez-vous habituellement avec un expert-comptable ou un cabinet d’expertise comptable ? Oui / Non Travaillez-vous habituellement avec un avocat ou un cabinet d’avocats ? Oui / Non Travaillez-vous avec un autre professionnel ou conseil intervenant dans la gestion de votre patrimoine ? Oui / Non Pour chaque réponse Oui, afficher conditionnellement les champs permettant d’identifier et de contacter le professionnel concerné. À minima, prévoir : nom et prénom du professionnel, lorsque pertinent ; nom de l’étude, du cabinet ou de la structure ; adresse e-mail ; numéro de téléphone ; éventuellement adresse postale ; pour « Autre professionnel », nature / qualité du professionnel. La logique doit permettre d’ajouter plusieurs professionnels d’une même catégorie si nécessaire. Par exemple, le client peut travailler avec plusieurs notaires ou plusieurs avocats intervenant sur des sujets différents. Autorisation de prise de contact Pour chaque professionnel renseigné, ajouter une question distincte : Autorisez-vous ASTRAEOS à prendre contact avec ce professionnel dans le cadre de la réalisation de votre étude patrimoniale ? Oui / Non Cette autorisation doit idéalement être gérée professionnel par professionnel. Exemple : Notaire A → contact autorisé : Oui Expert-comptable B → contact autorisé : Oui Avocat C → contact autorisé : Non La réponse doit être enregistrée dans le dossier et clairement visible par l’ingénieur patrimonial avant toute prise de contact. Il ne faut pas déduire une autorisation globale du seul fait que le client a renseigné les coordonnées d’un professionnel. Logique dans la configuration ingénieur Cette nouvelle rubrique doit s’intégrer au fonctionnement général du moteur de collecte. Si l’ingénieur patrimonial connaît déjà l’existence d’un professionnel habituel, il doit pouvoir renseigner l’information. Si l’information reste « À confirmer », la question correspondante doit être posée au client. Comme dans les autres sections, l’ingénieur patrimonial doit conserver la possibilité de cocher ou décocher manuellement les questions avant l’envoi de la collecte.

Intention : Identifier dès la collecte les professionnels déjà présents autour du client et disposer d’une vision structurée de son environnement de conseil. L’objectif est également de savoir explicitement avec quels professionnels ASTRAEOS est autorisé à échanger dans le cadre de l’étude patrimoniale, sans devoir redemander ultérieurement cette autorisation.

Gêne : Aujourd’hui, ces informations ne disposent d’aucune rubrique dédiée et peuvent être recueillies de manière informelle ou oubliées. Cela peut conduire l’ingénieur patrimonial à découvrir tardivement l’existence d’un notaire, d’un expert-comptable, d’un avocat ou d’un autre conseil déjà impliqué dans le dossier. Par ailleurs, sans question spécifique sur l’autorisation de prise de contact, il n’est pas possible de distinguer clairement : un professionnel simplement renseigné à titre informatif ; un professionnel avec lequel le client autorise effectivement ASTRAEOS à échanger.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section 11 – Informations complémentaires, plusieurs documents sont actuellement ajoutés automatiquement dans « Documents à demander au client » : Questionnaire patrimonial / DCI complété ; Lettre de mission ou mandat signé ; Qualification du profil risque ; DER ; Autorisation de traitement des données personnelles. Ces documents n’ont pas à être redemandés à ce stade. Ils ont déjà été produits, collectés ou enregistrés dans les étapes précédentes du parcours, notamment lors de la conformité et de la contractualisation. Les demander une nouvelle fois au client crée donc une ressaisie documentaire inutile et une incohérence dans le parcours.

Attendu : Supprimer de la section « Informations complémentaires » toutes les demandes automatiques relatives aux documents déjà présents dans le dossier, notamment : DCI / questionnaire patrimonial ; lettre de mission ; qualification du profil risque ; DER ; autorisation de traitement des données personnelles. Ces documents doivent rester accessibles à l’ingénieur patrimonial depuis le dossier existant, mais ne doivent pas apparaître comme des pièces à redemander au client dans la collecte documentaire. Dans cette section, la logique attendue est différente : elle doit permettre au client de transmettre, s’il le souhaite ou si l’ingénieur le lui demande, des documents complémentaires non couverts par les autres rubriques. La zone documentaire doit donc être libre et vierge par défaut, sans présélection de documents réglementaires ou contractuels déjà collectés. Si l’ingénieur souhaite demander une pièce complémentaire spécifique dans cette rubrique, il doit pouvoir l’ajouter manuellement via la fonction prévue d’ajout d’une demande de document hors référentiel.

Intention : Éviter toute redemande de pièces déjà présentes dans le dossier et réserver la rubrique « Informations complémentaires » aux éléments réellement complémentaires qui n’ont pas leur place dans les autres sections de la collecte.

Gêne : Le fonctionnement actuel : redemande au client des documents qu’il a déjà fournis ou signés ; donne l’impression que ces pièces sont manquantes alors qu’elles sont déjà enregistrées ; alourdit inutilement la collecte ; peut générer des doublons documentaires ; détourne la section « Informations complémentaires » de sa fonction réelle.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section 9 – Mutuelle et prévoyance, lorsqu’une prévoyance est déclarée par l’ingénieur patrimonial ou ultérieurement par le client, la logique actuelle semble considérer qu’il n’existe qu’un seul contrat. Par exemple, lorsque l’ingénieur indique : « Le client a-t-il une prévoyance individuelle ? » → Oui la collecte déclenche actuellement des demandes génériques telles que : contrat de prévoyance individuelle ; tableau de garanties prévoyance ; clause bénéficiaire de l’assurance décès. Or, un même client peut disposer de plusieurs contrats de prévoyance actifs simultanément. Il faut donc raisonner contrat par contrat, et non simplement « le client a / n’a pas une prévoyance ».

Attendu : Lorsqu’une prévoyance est identifiée, demander au client : Combien de contrats de prévoyance actifs détenez-vous actuellement ? La collecte doit ensuite créer une fiche distincte pour chaque contrat déclaré. Pour chaque contrat de prévoyance, il faut demander au minimum : le contrat / document de souscription ; le tableau des garanties ; la rédaction exacte de la clause bénéficiaire, lorsqu’une clause bénéficiaire existe dans le cadre du contrat concerné. Les éléments collectés doivent être rattachés au contrat correspondant. Il ne faut pas avoir trois documents génériques au niveau du foyer sans possibilité de savoir à quelle prévoyance ils se rapportent. Exemple de logique : 3 contrats actifs déclarés → Contrat de prévoyance n°1 : contrat + tableau de garanties + clause bénéficiaire → Contrat de prévoyance n°2 : contrat + tableau de garanties + clause bénéficiaire → Contrat de prévoyance n°3 : contrat + tableau de garanties + clause bénéficiaire Cette logique doit fonctionner quelle que soit l’origine de l’information : réponse renseignée par l’ingénieur patrimonial ou réponse obtenue auprès du client. Elle doit également fonctionner pour les différentes catégories de prévoyance déjà prévues dans la configuration : prévoyance individuelle, TNS, collective, et pour les différents membres du couple lorsqu’ils sont concernés.

Intention : Permettre à l’ingénieur patrimonial de disposer d’une vision exhaustive des couvertures de prévoyance réellement actives et de rapprocher sans ambiguïté chaque contrat de ses garanties et de sa clause bénéficiaire.

Gêne : Le fonctionnement actuel peut conduire à ne collecter qu’un seul jeu de documents alors que plusieurs prévoyances existent. Cela crée un risque : d’omission de contrats ; de garanties manquantes ; de confusion entre plusieurs contrats ; de rattachement d’une clause bénéficiaire au mauvais contrat ; d’analyse incomplète de la couverture du client et du foyer.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section 9 – Mutuelle et prévoyance, la question de qualification : « Le foyer a-t-il une mutuelle ? » déclenche actuellement des questions et documents conçus comme si le foyer ne pouvait disposer que d’un seul contrat de mutuelle. La collecte demande notamment un montant annuel de cotisation mutuelle et un contrat de mutuelle santé du client ou du foyer, ce qui ne permet pas de représenter les situations dans lesquelles plusieurs contrats coexistent. Or, un même foyer peut avoir plusieurs mutuelles distinctes, avec des souscripteurs et des personnes assurées différents. En présence d’enfants, il faut également pouvoir identifier précisément sur quel contrat chaque enfant est éventuellement rattaché.

Attendu : La question principale doit d’abord permettre d’identifier l’existence de contrats de mutuelle : Le foyer dispose-t-il d’une ou plusieurs mutuelles ? Oui / Non / À confirmer côté ingénieur, selon la logique générale du moteur. En cas de réponse Oui, la collecte client doit permettre de renseigner autant de contrats de mutuelle que nécessaire. Pour chaque contrat, il faut pouvoir identifier au minimum : le souscripteur / titulaire du contrat ; les personnes assurées par ce contrat ; lorsqu’il y a des enfants dans le foyer, les enfants rattachés à ce contrat ; les informations de cotisation et de garanties déjà prévues par la collecte lorsqu’elles sont utiles ; le document correspondant au contrat / tableau de garanties concerné. La logique ne doit donc plus être : une mutuelle = une cotisation = un document pour tout le foyer mais : une ou plusieurs mutuelles → une fiche par contrat → souscripteur → personnes couvertes → enfants éventuellement rattachés → documents correspondants. Si plusieurs enfants sont déjà connus dans le DCI, leurs identités doivent être reprises afin de pouvoir sélectionner précisément ceux qui sont couverts par chaque contrat, sans ressaisie inutile. Gestion des documents La demande documentaire doit elle aussi fonctionner par contrat. S’il existe plusieurs mutuelles, le client doit pouvoir transmettre les justificatifs correspondants pour chacune d’elles, par exemple le contrat et/ou le tableau de garanties associé. Les documents doivent rester rattachés au bon contrat afin que l’ingénieur patrimonial puisse distinguer facilement les différentes couvertures du foyer.

Intention : Permettre de représenter fidèlement la couverture santé réelle du foyer et éviter de supposer qu’une seule mutuelle couvre nécessairement tous ses membres. L’objectif est notamment d’identifier clairement : qui souscrit chaque contrat ; qui est effectivement couvert ; sur quel contrat les enfants sont rattachés ; quels justificatifs correspondent à chaque couverture.

Gêne : Le fonctionnement actuel peut conduire à fusionner artificiellement plusieurs mutuelles en un seul contrat, à perdre l’information sur les personnes réellement couvertes ou à ne pas savoir sur quel contrat sont rattachés les enfants. Cela limite ensuite la qualité de l’analyse des couvertures du foyer et complique le rapprochement entre les réponses du client et les documents collectés.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section « Fiscalité », les documents demandés sont actuellement trop centrés sur la déclaration générale et sur l’existence éventuelle d’un dispositif fiscal immobilier ou d’un autre avantage fiscal. Or, l’absence de dispositif fiscal particulier ne signifie pas que le foyer ne dépose pas d’autres déclarations fiscales. Le client peut notamment avoir des revenus ou activités donnant lieu à des déclarations spécifiques. Dans les cas rencontrés, il peut par exemple être nécessaire de récupérer une 2044, une 2031 ou une 2035, selon la situation du foyer. De la même manière, il peut exister plusieurs types d’avis fiscaux utiles au dossier. La collecte ne doit donc pas se limiter automatiquement à une déclaration 2042 et aux seuls justificatifs liés aux dispositifs de réduction ou de crédit d’impôt.

Attendu : Dans la section Fiscalité, ajouter une logique permettant d’identifier les différentes déclarations fiscales effectivement déposées par le foyer, indépendamment de la question : « Le foyer bénéficie-t-il d’un dispositif fiscal immobilier ? » et de celle relative aux autres investissements ou dispositifs ouvrant droit à un avantage fiscal. La collecte pourrait comporter une question générale du type : Le foyer dépose-t-il d’autres déclarations fiscales en complément de sa déclaration habituelle de revenus ? Puis permettre d’identifier les déclarations concernées, par exemple : déclaration 2044 ; déclaration 2031 ; déclaration 2035 ; autres déclarations ou annexes fiscales à préciser. La liste doit rester suffisamment ouverte pour permettre au client ou à l’ingénieur patrimonial d’indiquer un document qui ne serait pas prévu dans le référentiel. Selon les réponses, les documents correspondants doivent alors être ajoutés automatiquement dans « Documents à demander au client ». Même principe pour les avis fiscaux : la collecte doit permettre de demander les différents avis pertinents disponibles dans le dossier, et non fonctionner comme si un seul type d’avis existait. Logique conditionnelle attendue Cette collecte documentaire ne doit pas dépendre uniquement de l’existence d’un dispositif fiscal. Par exemple, un foyer peut ne bénéficier d’aucun dispositif fiscal immobilier tout en ayant des revenus fonciers ou une activité liée à un bien immobilier meublé. Les déclarations fiscales correspondantes doivent pouvoir être identifiées et demandées indépendamment. Si l’ingénieur patrimonial connaît déjà les déclarations concernées, il doit pouvoir les sélectionner directement. S’il ne les connaît pas, la question doit être posée au client conformément à la logique générale : information inconnue / À confirmer → question au client → réponse → ajout conditionnel des documents correspondants. L’ingénieur patrimonial doit également conserver la possibilité de cocher, décocher ou ajouter manuellement une déclaration ou un avis dans la collecte finale.

Intention : Obtenir une collecte fiscale réellement représentative de la situation du foyer et éviter d’assimiler à tort : absence de dispositif fiscal = absence de déclarations fiscales complémentaires. L’objectif est que l’ingénieur patrimonial dispose dès la collecte des déclarations et avis nécessaires à l’analyse du dossier, sans devoir découvrir ultérieurement qu’une catégorie de document fiscal n’a jamais été demandée.

Gêne : Le fonctionnement actuel peut conduire à ne pas demander certains documents fiscaux alors que le client les établit effectivement. Cela peut générer : une collecte fiscale incomplète ; une analyse retardée ; une nouvelle sollicitation du client après réception du dossier ; une mauvaise compréhension de l’origine ou de la nature de certains revenus ; des demandes documentaires trop dépendantes des seules questions relatives aux dispositifs fiscaux.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, l’ingénieur patrimonial dispose actuellement, tout en haut de la page, d’un bouton : « Ajouter une pièce » Ce libellé est trop restrictif, car l’ingénieur doit pouvoir enrichir manuellement la collecte de deux types d’éléments différents : une question à poser au client ; une demande de document à transmettre par le client. Le cadre qui s’ouvre actuellement est intitulé « Nouvelle pièce hors-référentiel » et ne permet de rédiger qu’un intitulé de pièce puis de choisir un thème. Il faut donc faire évoluer cette fonctionnalité pour couvrir les deux usages.

Attendu : Renommer le bouton principal, par exemple : Ajouter une question / une demande de document Au clic, afficher un bloc qui pourrait être intitulé : Nouvel élément hors référentiel L’ingénieur patrimonial doit alors choisir entre deux types d’ajout. 1. Ajouter une question L’ingénieur sélectionne « Question », puis peut : rédiger librement la question à poser au client ; choisir le thème / la section dans laquelle cette question doit apparaître ; valider l’ajout. La question doit ensuite apparaître dans la rubrique choisie, dans : Questions à poser au client Elle doit être cochée / sélectionnée dans la collecte et rester modifiable ou supprimable avant l’envoi. 2. Ajouter une demande de document L’ingénieur sélectionne « Demande de document », puis peut : indiquer librement le document qu’il souhaite obtenir ; choisir le thème / la section dans laquelle cette demande doit apparaître ; valider l’ajout. La demande doit ensuite apparaître dans la rubrique choisie, dans : Documents à demander au client Elle doit également pouvoir être retirée ou modifiée avant l’envoi. Comportement attendu Le choix du type doit déterminer automatiquement l’endroit où l’élément sera ajouté : Question → « Questions à poser au client » Demande de document → « Documents à demander au client » Le champ Thème doit permettre de rattacher l’élément à l’une des sections existantes de la collecte : Identité et situation familiale, Budget, Fiscalité, Patrimoine professionnel, Immobilier, Actifs financiers, etc. Ces ajouts manuels doivent compléter le moteur automatique de collecte sans modifier les règles conditionnelles existantes.

Intention : Donner à l’ingénieur patrimonial la possibilité d’adapter finement une collecte à un dossier particulier, même lorsqu’une question ou une pièce n’existe pas encore dans le référentiel standard. L’outil doit clairement distinguer une information à demander au client d’un document à collecter.

Gêne : Le fonctionnement actuel assimile tout ajout manuel à une « pièce », alors que le besoin peut simplement être de poser une question complémentaire. Cela oblige soit à détourner la fonctionnalité existante, soit à renoncer à intégrer directement certaines demandes spécifiques dans la collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Oui. Le ticket gagnerait à être élargi à l’ensemble du moteur de configuration de la collecte documentaire, car le problème n’est pas propre à la fiscalité : c’est une règle de fonctionnement générale. Titre du ticket Généraliser la logique conditionnelle « À confirmer → question au client » à toutes les sections de la collecte documentaire, avec possibilité d’ajustement manuel par l’ingénieur patrimonial Problème / demande Lors de la configuration de la collecte documentaire, les questions de qualification renseignées par l’ingénieur patrimonial ne déclenchent pas toujours correctement les questions à poser au client, les demandes de précisions ou les documents associés. Le problème a été constaté dans plusieurs rubriques, notamment Budget et Fiscalité, mais il doit être traité comme un problème de fonctionnement global du moteur conditionnel. Le principe attendu est simple : lorsqu’une information est encore « À confirmer », cela signifie que l’ingénieur patrimonial ne dispose pas de la réponse. La plateforme doit donc automatiquement organiser la récupération de cette information auprès du client. Cette logique doit fonctionner de manière homogène dans toutes les sections de configuration de la collecte documentaire.

Attendu : Pour chaque question de qualification proposée à l’ingénieur patrimonial, appliquer la logique générale suivante : À confirmer → ajouter automatiquement la question correspondante dans « Questions à poser au client » ; Oui → ne pas reposer inutilement la question principale au client, mais déclencher les questions complémentaires, précisions et/ou documents associés à une réponse positive ; Non → ne pas reposer la question et retirer les questions ou documents devenus inutiles. Cette règle doit être appliquée sur l’ensemble des sections, notamment : Identité et situation familiale ; Budget ; Fiscalité ; Patrimoine professionnel ; Immobilier ; Actifs financiers ; Passifs et créances ; Retraite ; Mutuelle et prévoyance ; et toute autre rubrique utilisant le même moteur de qualification et de collecte. Même moteur conditionnel côté ingénieur et côté client Si l’ingénieur laisse une information à « À confirmer », la question est posée au client. Lorsque le client répond ensuite, sa réponse doit elle-même alimenter le moteur conditionnel. Exemple : Ingénieur : « Le foyer est-il assujetti à l’IFI ? » → À confirmer ↓ La question est ajoutée à la collecte client ↓ Client : Oui ↓ Le moteur déclenche automatiquement les éventuelles questions complémentaires et/ou pièces nécessaires. La logique doit donc fonctionner quel que soit l’endroit où la réponse initiale est obtenue : réponse ingénieur ou réponse client → mêmes conséquences conditionnelles. Conserver la maîtrise manuelle de l’ingénieur patrimonial Le moteur doit précomposer automatiquement la collecte, mais l’ingénieur patrimonial doit conserver la possibilité de l’ajuster avant envoi. Il doit donc pouvoir : cocher une question pour l’ajouter manuellement à la collecte ; décocher une question proposée automatiquement s’il estime qu’elle n’est pas pertinente dans le dossier ; ajouter ou retirer de la même manière les documents lorsque l’interface le permet. L’objectif n’est donc pas de rendre la collecte entièrement automatique et verrouillée. Le fonctionnement attendu est : moteur conditionnel = proposition automatique pertinente ingénieur patrimonial = validation et ajustement final de la collecte Les choix manuels effectués par l’ingénieur doivent être clairement pris en compte dans la composition finale envoyée au client.

Intention : Créer une règle de fonctionnement unique et prévisible pour toute la collecte documentaire : ce qui est déjà connu n’est pas redemandé ; ce qui reste inconnu est demandé au client ; les réponses déclenchent automatiquement les précisions et documents nécessaires ; l’ingénieur patrimonial conserve la maîtrise finale de la composition.

Gêne : Aujourd’hui, le comportement varie selon les rubriques et les questions. Une information peut rester « À confirmer » sans jamais être demandée au client, alors qu’une autre question fonctionne correctement. Cela peut produire une collecte apparemment complète mais comportant encore des informations inconnues, avec des questions ou justificatifs manquants. À l’inverse, un moteur totalement automatique sans possibilité de décocher certains éléments serait trop rigide pour l’ingénieur patrimonial. Il faut donc combiner automatisation conditionnelle + contrôle manuel final.

/espace-ingenieur/modifications

Problème : Lors de la configuration de la collecte documentaire, dans la section « Budget », l’ingénieur patrimonial doit notamment qualifier les deux questions suivantes : « Le foyer perçoit-il des dividendes ? » « Le foyer perçoit-il des revenus financiers (IFU) ? » Actuellement, lorsque l’ingénieur patrimonial ne connaît pas la réponse et laisse ces questions au statut « À confirmer », cela n’a aucun impact sur la collecte générée. Les questions ne sont notamment pas ajoutées dans « Questions à poser au client ». Cela crée une rupture dans la logique attendue du moteur conditionnel : si l’ingénieur ne connaît pas une information de qualification, cette information doit justement être demandée au client pendant la collecte.

Attendu : Appliquer pour ces deux questions la logique conditionnelle suivante : À confirmer → ajouter automatiquement la question correspondante dans « Questions à poser au client » ; Non → ne pas poser inutilement la question au client et ne pas déclencher les éléments associés ; Oui → considérer l’information comme déjà connue et ne pas reposer la même question au client ; déclencher uniquement les éventuelles questions complémentaires ou pièces nécessaires prévues par le moteur. Ainsi, si l’ingénieur laisse les deux champs à « À confirmer », la collecte client doit notamment comporter : Le foyer perçoit-il des dividendes ? Oui / Non et Le foyer perçoit-il des revenus financiers donnant lieu à un IFU ? Oui / Non Les réponses apportées ensuite par le client doivent à leur tour alimenter le moteur conditionnel et déclencher, le cas échéant, les questions complémentaires et/ou documents correspondants.

Intention : Faire de « À confirmer » un véritable état fonctionnel : lorsque l’ingénieur patrimonial ne dispose pas encore de l’information, la collecte doit permettre de la récupérer auprès du client au lieu de laisser le point sans réponse.

Gêne : En l’état, une information laissée volontairement « À confirmer » peut ne jamais être redemandée au client. L’ingénieur peut donc recevoir une collecte complète en apparence alors que deux informations relatives aux revenus financiers sont toujours inconnues, avec un risque de devoir recontacter ensuite le client et de compléter manuellement le dossier.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section « Identité et situation familiale », lorsque l’ingénieur patrimonial répond « Oui » à la question : « Un enfant est-il décédé ? » aucune question complémentaire n’est actuellement ajoutée à la collecte. Or, l’existence de descendants de cet enfant décédé peut être déterminante pour l’analyse familiale et successorale du dossier. Il est donc utile d’identifier si cet enfant avait lui-même des enfants ou autres descendants susceptibles d’être concernés par une succession.

Attendu : Lorsque l’ingénieur patrimonial sélectionne : Un enfant est-il décédé ? → Oui le moteur conditionnel doit ajouter une question à poser au client, par exemple : L’enfant décédé avait-il lui-même des descendants ? Oui / Non En cas de réponse Oui, demander ensuite d’identifier les personnes concernées, idéalement sous forme structurée : nom ; prénom ; lien avec l’enfant décédé ; date de naissance complète ; éventuellement rattachement à l’enfant décédé concerné lorsqu’il existe plusieurs enfants. Si plusieurs enfants du foyer sont renseignés, la collecte doit également permettre d’identifier quel enfant est décédé, plutôt que de rester sur une question générique. Les personnes ainsi renseignées devraient pouvoir alimenter ou être rapprochées du tableau général « Famille et personnes pouvant être concernées par le patrimoine », afin d’éviter une double saisie.

Intention : Permettre à l’ingénieur patrimonial d’identifier dès la collecte les descendants d’un enfant décédé susceptibles d’avoir une incidence sur l’analyse successorale et la dévolution future, sans devoir rechercher cette information manuellement plus tard.

Gêne : En l’état, le fait qu’un enfant soit décédé est enregistré, mais aucune information n’est collectée sur sa propre descendance. Le dossier familial peut donc rester incomplet sur un élément potentiellement important pour l’analyse successorale, notamment lorsqu’un descendant de l’enfant décédé est susceptible d’être concerné par la succession.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Dans la configuration de la collecte documentaire, section « Identité et situation familiale », il manque une question structurante qui doit être posée au client dans tous les dossiers, indépendamment des réponses renseignées par l’ingénieur patrimonial dans les questions de qualification. L’objectif est de permettre au client de déclarer les membres de sa famille et, plus largement, les personnes susceptibles d’être concernées directement ou indirectement par son patrimoine. Cette information ne doit donc pas dépendre d’un déclencheur conditionnel. Elle doit être intégrée automatiquement à la collecte.

Attendu : Dans « Questions à poser au client », ajouter systématiquement une question du type : Famille et personnes pouvant être concernées par votre patrimoine Afin de mieux comprendre votre contexte familial et patrimonial au-delà de votre cellule familiale, veuillez renseigner les personnes pouvant être concernées, directement ou indirectement, par votre patrimoine. Le texte peut notamment préciser qu’il peut s’agir : des parents ; des frères et sœurs ; de personnes mentionnées dans un testament ou susceptibles d’être concernées par une transmission ; de personnes avec lesquelles un bien est détenu en indivision ou en démembrement ; plus généralement, de toute personne ayant un lien patrimonial pertinent avec le client ou son conjoint / partenaire / concubin. La réponse doit prendre la forme d’un tableau permettant d’ajouter autant de lignes que nécessaire, avec exactement les informations suivantes : Colonne Information attendue Nom Nom de la personne Prénom Prénom de la personne Lien de parenté / relation Père, mère, frère, sœur, neveu, tiers, etc. Rattaché à Client ou conjoint / partenaire / concubin Date de naissance Date complète, idéalement au format JJ/MM/AAAA, et non uniquement l’année Le client doit pouvoir ajouter, modifier et supprimer des lignes simplement. Cette question doit être : présente automatiquement dans toutes les collectes ; non conditionnée à une réponse de l’ingénieur patrimonial ; intégrée par défaut à la collecte, puisqu’elle est utile quelle que soit la configuration familiale connue à ce stade. Il faut bien distinguer « question obligatoirement posée » et « obligation de renseigner au moins une personne » : la question doit toujours être présentée au client, mais le fonctionnement ne doit pas inventer une personne lorsqu’aucune personne supplémentaire pertinente n’est à déclarer.

Intention : Obtenir dès la collecte une vision plus complète de l’environnement familial et patrimonial du client, au-delà du seul couple et des enfants déjà enregistrés dans le DCI. Ces informations permettront ensuite à l’ingénieur patrimonial d’identifier plus facilement les personnes susceptibles d’avoir une incidence sur une succession, une transmission, une indivision, un démembrement ou toute autre situation patrimoniale nécessitant une analyse.

Gêne : La collecte actuelle se concentre principalement sur la cellule familiale immédiate et ne permet pas de recenser de manière structurée les autres personnes susceptibles d’être déterminantes pour l’analyse patrimoniale. Ces informations doivent alors être récupérées manuellement plus tard, avec un risque d’oubli et sans structure homogène dans le dossier.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/9fa5cc6c-3fe4-41af-935a-274300829f91

Problème : À l’étape 2 – Conformité en cours, l’ingénieur patrimonial ne dispose actuellement d’aucune action permettant de supprimer un dossier. Or, un prospect peut avoir commencé le parcours de contractualisation puis finalement décider de ne pas donner suite. Dans ce cas, le dossier reste inutilement présent dans la phase de conformité alors qu’il ne doit plus poursuivre le parcours. Cette possibilité existe déjà à l’étape 1 – Prospects et doit être conservée lorsque le dossier a basculé en conformité.

Attendu : Ajouter, sur la fiche du dossier en Conformité en cours, une action : Supprimer L’action pourrait être positionnée en bas à droite de la page, dans la zone des actions du dossier, de manière cohérente avec le fonctionnement de l’étape Prospects. Au clic sur « Supprimer », afficher obligatoirement une fenêtre de confirmation afin d’éviter toute suppression accidentelle. Par exemple : Supprimer ce dossier ? Cette action supprimera le dossier du parcours en cours. Souhaitez-vous continuer ? Actions proposées : Annuler Confirmer la suppression Si l’ingénieur patrimonial confirme, la suppression doit être effectivement réalisée et le dossier ne doit plus apparaître dans la liste « Conformité en cours ». Principe de fonctionnement Le comportement doit être identique à celui déjà disponible à l’étape 1 – Prospects : même logique de suppression ; même niveau de confirmation ; même traitement effectif du dossier après validation. Il ne doit pas être nécessaire de revenir artificiellement à l’étape Prospect pour pouvoir supprimer un dossier qui ne contractualisera finalement pas.

Intention : Permettre à l’ingénieur patrimonial de maintenir un pipeline propre et de retirer les dossiers abandonnés lorsque le prospect renonce à contractualiser après son passage en conformité.

Gêne : En l’état : les dossiers abandonnés restent bloqués dans « Conformité en cours » ; les statistiques et volumes de dossiers en conformité peuvent devenir artificiellement gonflés ; l’ingénieur ne peut pas nettoyer son portefeuille ; le parcours ne permet pas de gérer correctement un prospect qui se désengage après le passage à l’étape 2.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/9fa5cc6c-3fe4-41af-935a-274300829f91

Problème : Sur la page « Conformité en cours », l’en-tête du dossier affiche actuellement : Tristan LANGLOIS & Sarah pabois Le nom de famille du second membre du couple apparaît en minuscules, contrairement à celui du premier membre. L’affichage n’est donc pas homogène avec la convention retenue dans le reste du parcours, où les noms de famille doivent apparaître en majuscules.

Attendu : L’en-tête doit afficher les deux identités selon la même convention : Tristan LANGLOIS & Sarah PABOIS La règle d’affichage doit être appliquée automatiquement aux deux membres du couple, indépendamment de la casse utilisée lors de la saisie initiale des données. Cette homogénéisation doit également être vérifiée dans les autres emplacements de la page où les identités du foyer sont reprises.

Intention : Garantir un affichage cohérent et homogène des identités sur l’ensemble du parcours ASTRAEOS.

Gêne : En l’état : les deux membres du couple ne sont pas présentés selon la même convention ; cela donne une impression d’incohérence dans la qualité de présentation du dossier ; le rendu diffère des autres écrans où les noms de famille sont affichés en majuscules.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 5 sur 22 du DCI complet – Situation du couple, la section : « Donations entre époux » reste affichée même lorsque le prospect sélectionne un statut d’union autre que « Marié(e) ». Dans l’exemple présenté, le couple est pacsé, mais la question suivante apparaît malgré tout : « Avez-vous mis en place une donation entre époux ? » Cette question n’est pas cohérente avec le statut d’union sélectionné.

Attendu : La section « Donations entre époux » doit être conditionnée au statut matrimonial. Si le statut sélectionné est « Marié(e) » : afficher la section ; permettre de répondre à la question relative à la donation entre époux. Pour tout autre statut d’union, notamment : Pacsé(e) ; concubinage / union libre ; célibataire ; divorcé(e) ; veuf / veuve ; la section « Donations entre époux » ne doit pas apparaître. La modification du statut doit entraîner immédiatement l’apparition ou la disparition du bloc correspondant.

Intention : Adapter dynamiquement les questions du DCI complet à la situation juridique réellement déclarée par le foyer et éviter de présenter au prospect des questions qui ne correspondent pas à son statut d’union.

Gêne : En l’état : un couple pacsé peut être interrogé sur une « donation entre époux » ; le prospect peut penser qu’il doit répondre à une question qui ne concerne pas sa situation ; cela introduit une incohérence dans le DCI complet ; cela alourdit inutilement le questionnaire.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/9fa5cc6c-3fe4-41af-935a-274300829f91

Problème : À l’étape 2 – Conformité en cours, lorsque l’ingénieur patrimonial modifie la lettre de mission et renseigne le montant des honoraires dans le champ prévu à cet effet, la valeur saisie n’est pas automatiquement mise en forme comme un montant monétaire. Dans l’exemple présenté, la saisie apparaît ainsi : 3900 alors qu’elle devrait être affichée avec une présentation monétaire homogène. Ce champ étant désormais synchronisé avec les différents emplacements où les honoraires sont repris dans le dossier, une saisie mal formatée peut également conduire à un affichage incohérent ailleurs dans l’interface ou dans les documents générés. Ce que cela devrait faire Le champ « Honoraires » doit appliquer automatiquement le format monétaire utilisé dans le reste de la plateforme. Par exemple : 3 900 € La mise en forme doit notamment intégrer : le séparateur de milliers ; le symbole € ; une présentation homogène avec les autres montants du dossier. L’ingénieur doit pouvoir saisir simplement : 3900 et le champ doit automatiquement l’afficher sous la forme : 3 900 € La valeur enregistrée doit ensuite être reprise avec cette même présentation dans tous les emplacements synchronisés, notamment : l’aperçu de la lettre de mission ; le PDF généré ; les autres blocs de la page Conformité affichant les honoraires ; la facture ou les autres documents reprenant ce montant, lorsque la synchronisation existe. Principe général à respecter La valeur monétaire doit être distinguée de son format d’affichage. Le champ doit conserver une donnée exploitable pour les calculs et synchronisations, tout en présentant systématiquement à l’utilisateur un montant correctement formaté. Cette règle doit rester cohérente avec le principe déjà retenu pour les autres champs monétaires de la plateforme : séparateurs de milliers + symbole €

Attendu : À l’étape 2 – Conformité en cours, lorsque l’ingénieur patrimonial modifie la lettre de mission et renseigne le montant des honoraires dans le champ prévu à cet effet, la valeur saisie n’est pas automatiquement mise en forme comme un montant monétaire. Dans l’exemple présenté, la saisie apparaît ainsi : 3900 alors qu’elle devrait être affichée avec une présentation monétaire homogène. Ce champ étant désormais synchronisé avec les différents emplacements où les honoraires sont repris dans le dossier, une saisie mal formatée peut également conduire à un affichage incohérent ailleurs dans l’interface ou dans les documents générés. Ce que cela devrait faire Le champ « Honoraires » doit appliquer automatiquement le format monétaire utilisé dans le reste de la plateforme. Par exemple : 3 900 € La mise en forme doit notamment intégrer : le séparateur de milliers ; le symbole € ; une présentation homogène avec les autres montants du dossier. L’ingénieur doit pouvoir saisir simplement : 3900 et le champ doit automatiquement l’afficher sous la forme : 3 900 € La valeur enregistrée doit ensuite être reprise avec cette même présentation dans tous les emplacements synchronisés, notamment : l’aperçu de la lettre de mission ; le PDF généré ; les autres blocs de la page Conformité affichant les honoraires ; la facture ou les autres documents reprenant ce montant, lorsque la synchronisation existe. Principe général à respecter La valeur monétaire doit être distinguée de son format d’affichage. Le champ doit conserver une donnée exploitable pour les calculs et synchronisations, tout en présentant systématiquement à l’utilisateur un montant correctement formaté. Cette règle doit rester cohérente avec le principe déjà retenu pour les autres champs monétaires de la plateforme : séparateurs de milliers + symbole €

Intention : Uniformiser l’affichage des honoraires sur l’ensemble du dossier et éviter qu’un montant correctement renseigné soit présenté sous une forme brute ou différente selon l’écran consulté.

Gêne : En l’état : la saisie « 3900 » est moins lisible que « 3 900 € » ; l’affichage n’est pas homogène avec les autres montants patrimoniaux ; le montant étant synchronisé à plusieurs endroits, une mauvaise mise en forme peut se propager dans plusieurs écrans ou documents ; cela oblige potentiellement à corriger l’affichage à plusieurs endroits au lieu de traiter la donnée correctement dès sa saisie.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10

Problème : À l’étape 3 – Collecte et analyse documentaire, lorsque l’ingénieur patrimonial clique sur « Initier une collecte », une page intermédiaire s’affiche avant l’accès au configurateur. Cette page indique actuellement : « Aucune collecte ouverte pour ce dossier » puis propose le bouton : « Préparer la collecte » Dans le cas présenté, le message selon lequel aucune collecte n’est encore ouverte est cohérent au sens où aucun lien de collecte n’a encore été envoyé au client. En revanche, une configuration de collecte documentaire avait déjà été commencée et sauvegardée par l’ingénieur patrimonial. L’interface ne distingue donc pas actuellement : l’absence totale de préparation ; l’existence d’un brouillon de collecte déjà configuré en partie ; l’existence d’une collecte effectivement envoyée et ouverte au client. Le bouton « Préparer la collecte » donne ainsi l’impression qu’aucun travail n’a encore été réalisé.

Attendu : La page intermédiaire doit tenir compte de l’état réel de la collecte. Si aucune configuration n’a encore été commencée : le fonctionnement actuel peut être conservé, par exemple : Aucune collecte ouverte pour ce dossier Aucune collecte n’a encore été préparée ou envoyée. Bouton : Préparer la collecte Si une configuration a déjà été commencée mais n’a pas encore été envoyée : l’interface doit indiquer clairement qu’un brouillon de collecte existe déjà. Par exemple : Configuration de la collecte en cours Une collecte documentaire a déjà été préparée pour ce dossier mais n’a pas encore été envoyée au client. Vous pouvez reprendre sa configuration. Bouton : Reprendre la configuration ou : Reprendre la collecte Le clic doit rouvrir le brouillon existant dans son dernier état sauvegardé, sans créer une nouvelle collecte ni réinitialiser les réponses et sélections déjà effectuées. Si une collecte a déjà été envoyée : la page doit alors afficher son véritable statut et proposer les actions adaptées à cette phase, plutôt qu’un bouton de préparation. États à distinguer Il serait utile que l’écran différencie au minimum : Aucune collecte préparée → Préparer la collecte Configuration en cours / brouillon enregistré → Reprendre la configuration Collecte envoyée / en cours auprès du client → Consulter ou suivre la collecte Collecte reçue / à analyser → Accéder à la collecte et aux documents reçus Les libellés précis peuvent être adaptés, mais l’état affiché doit correspondre au véritable avancement du dossier.

Intention : Permettre à l’ingénieur patrimonial de comprendre immédiatement où en est la collecte documentaire et de reprendre un travail déjà commencé sans avoir l’impression de devoir repartir de zéro. Cette logique doit rester cohérente avec la sauvegarde dynamique de la configuration de la collecte.

Gêne : En l’état : l’interface indique implicitement qu’aucune préparation n’existe alors qu’un brouillon est déjà enregistré ; l’ingénieur peut craindre que son travail précédent ait été perdu ; le bouton « Préparer la collecte » ne reflète pas l’action réellement attendue ; les différents états du cycle de vie de la collecte ne sont pas suffisamment distingués.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, le parcours comporte actuellement trois sous-étapes : Composition des pièces Destinataires Envoi & confirmation Pourtant, le bouton : « Passer à l’étude (étape 04) » est déjà disponible à chacune de ces sous-étapes. L’ingénieur patrimonial peut donc théoriquement faire passer le dossier en étape 4 – Études en cours alors que : la composition de la collecte n’est pas nécessairement terminée ; les destinataires ne sont pas encore configurés ; la collecte n’a pas encore été envoyée ; le client n’a pas encore transmis l’ensemble des éléments demandés ; les pièces reçues n’ont pas encore été analysées par l’ingénieur patrimonial. Le passage à l’étude est donc proposé beaucoup trop tôt dans le parcours.

Attendu : Le bouton « Passer à l’étude (étape 04) » ne doit pas être disponible pendant les phases de préparation et d’envoi de la collecte. Il doit rester masqué ou désactivé tant que la collecte documentaire n’a pas atteint un niveau suffisant d’avancement. A minima, le passage en étape 4 doit nécessiter que : la composition de la collecte soit finalisée ; les destinataires soient définis ; la collecte ait été envoyée ; les réponses et documents attendus aient été retournés ; les pièces reçues aient été examinées par l’ingénieur patrimonial ; l’ingénieur ait validé que la collecte est suffisamment complète et exploitable pour démarrer l’étude. Le passage en Études en cours doit donc intervenir à la fin réelle de l’étape 3, et non pendant sa préparation. Comportement attendu Pendant : Composition des pièces Destinataires Envoi & confirmation le bouton « Passer à l’étude (étape 04) » ne doit pas permettre de faire avancer le dossier. Une fois la collecte envoyée, le dossier doit rester en étape 3 – Collecte et analyse documentaire pendant : la réception progressive des réponses et documents ; les éventuelles relances ; l’analyse des pièces reçues ; la vérification de leur complétude et de leur exploitabilité. Ce n’est qu’après validation de cette phase par l’ingénieur patrimonial que le bouton de passage à l’étape 4 doit devenir disponible.

Intention : Faire correspondre le changement d’étape au véritable état d’avancement du dossier. L’étape 3 ne correspond pas uniquement à la préparation et à l’envoi d’une liste de pièces : elle couvre également la collecte effective et l’analyse documentaire. L’étude patrimoniale ne doit donc pouvoir commencer qu’une fois cette matière suffisamment collectée et contrôlée.

Gêne : En l’état : un dossier peut être passé en étude alors que la collecte n’est même pas envoyée ; les étapes du parcours ne reflètent plus la réalité opérationnelle ; l’ingénieur peut démarrer formellement une étude sans disposer des éléments nécessaires ; cela fragilise le suivi de l’avancement des dossiers ; les indicateurs et tableaux de bord peuvent présenter comme « en étude » des dossiers encore en pleine collecte documentaire.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, une fois la composition de la collecte terminée, l’ingénieur patrimonial arrive à l’étape 2 – Destinataires pour déterminer à qui envoyer la collecte. Dans le dossier testé, il s’agit d’un couple identifié comme tel depuis le début du parcours. Pourtant, l’écran ne reprend automatiquement que : Tristan LANGLOIS Le second membre du couple n’apparaît pas et l’adresse e-mail du premier membre n’est elle-même pas préremplie. L’ingénieur doit donc ressaisir manuellement des données d’identité et de contact qui existent déjà dans le dossier.

Attendu : Lorsque le dossier concerne un couple, l’étape « Destinataires » doit automatiquement créer une ligne pour chacun des deux membres du foyer, avec les informations déjà disponibles dans le dossier. Par exemple : Tristan LANGLOIS — adresse e-mail de Tristan Sarah PABOIS — adresse e-mail de Sarah Les champs doivent être alimentés à partir des données du dossier sans nouvelle saisie de l’ingénieur patrimonial. La logique doit être : dossier individuel → 1 destinataire prérempli ; dossier couple → 2 destinataires préremplis ; chaque personne reçoit sa propre collecte et son propre lien lorsque le fonctionnement de cette étape le prévoit. Les champs peuvent rester modifiables avant envoi si nécessaire. Si une adresse e-mail est réellement absente du dossier, le membre du foyer doit malgré tout apparaître comme destinataire, avec une indication claire que son adresse reste à renseigner. L’absence d’e-mail ne doit pas conduire à faire disparaître complètement la personne. Cohérence avec le dossier Les identités et adresses e-mail doivent provenir exclusivement du dossier actuellement ouvert. Aucune ressaisie ne devrait être nécessaire lorsque l’information a déjà été collectée aux étapes précédentes. Dans le cas d’un couple, le second membre ne doit pas être traité comme un « destinataire supplémentaire » à ajouter manuellement : il fait déjà partie du foyer étudié.

Intention : Fluidifier l’envoi de la collecte documentaire et conserver une continuité des données entre les différentes étapes du parcours. L’objectif est que l’ingénieur patrimonial n’ait pas à reconstituer manuellement les destinataires d’un dossier alors que leurs identités et coordonnées sont déjà connues de la plateforme.

Gêne : En l’état : l’ingénieur doit ressaisir des informations déjà présentes ; le second membre du couple peut être oublié ; une collecte peut être envoyée à une seule personne alors que l’étude concerne les deux membres du foyer ; cela augmente le risque d’erreur d’adresse ou de mauvais rattachement ; l’écran n’est pas cohérent avec le reste du parcours, dans lequel le dossier est bien traité comme un dossier couple.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Identité et situation familiale », l’ingénieur patrimonial peut indiquer que le foyer a des enfants. Cependant, la suite de la collecte semble actuellement construite comme si le foyer ne pouvait avoir qu’un seul enfant. On retrouve notamment : une demande générique de « Pièce d’identité de l’enfant » ; la question « L’enfant est-il issu du client, du conjoint, du couple ou d’une autre union ? » ; la question « L’enfant est-il adopté ? » ; la question « L’enfant est-il décédé ? ». Ces formulations et cette logique ne permettent pas de traiter correctement un foyer comprenant plusieurs enfants, notamment lorsqu’ils n’ont pas tous la même filiation. Exemple : dans une famille recomposée, certains enfants peuvent être issus du couple actuel, d’autres d’une précédente union de Monsieur ou de Madame.

Attendu : Lorsque le foyer comporte plusieurs enfants, la collecte doit fonctionner enfant par enfant. Les enfants déjà connus dans le DCI complet ou dans le dossier doivent être repris individuellement avec leur identité. Pour chaque enfant, la collecte doit permettre de qualifier uniquement les informations qui restent nécessaires, notamment : son identité ; de quelle union ou de quel membre du foyer il est issu ; s’il est adopté ; s’il est décédé ; les autres informations familiales pertinentes déjà prévues dans la collecte. Les questions ne doivent donc plus être formulées de manière générique comme : « L’enfant est-il adopté ? » mais être rattachées à l’enfant concerné, par exemple : « [Prénom NOM] est-il adopté ? » ou, lorsque l’information générale n’est pas encore connue : « Un ou plusieurs enfants sont-ils adoptés ? » puis, si Oui : « Quel(s) enfant(s) sont concernés ? » Même logique pour le décès d’un enfant ou son rattachement à une précédente union. Gestion de la filiation La collecte doit permettre de distinguer notamment : enfant issu du couple actuel ; enfant de Monsieur issu d’une précédente union ; enfant de Madame issu d’une précédente union ; enfant adopté ; autre situation à préciser si nécessaire. Il ne faut pas appliquer automatiquement une même réponse à tous les enfants du foyer. Documents à demander Les demandes documentaires doivent également être gérées par enfant. Par exemple, une demande générique : « Pièce d’identité de l’enfant » n’est pas suffisamment précise lorsqu’il existe plusieurs enfants. La collecte doit permettre d’identifier clairement les pièces attendues pour chaque enfant concerné. De même, les éventuels documents relatifs à une adoption, un décès ou une situation spécifique doivent être demandés uniquement pour l’enfant concerné. Reprise des données déjà connues Les informations déjà renseignées dans le DCI complet doivent être réutilisées pour éviter de recréer manuellement la structure familiale. Si le DCI complet contient déjà : le nombre d’enfants ; leurs identités ; leur filiation ; une adoption ; un décès ; ces données doivent alimenter la configuration de la collecte. Seules les informations encore manquantes doivent être demandées au client.

Intention : Permettre à la collecte documentaire de représenter correctement les familles avec plusieurs enfants et les familles recomposées, sans simplifier artificiellement la situation à un enfant unique. L’objectif est également de rattacher chaque question et chaque document à la bonne personne du foyer.

Gêne : En l’état : la collecte semble supposer qu’il n’existe qu’un seul enfant ; les questions sont ambiguës dès qu’il y en a plusieurs ; la filiation de chaque enfant ne peut pas être distinguée correctement ; les documents demandés ne sont pas clairement rattachés à un enfant précis ; une famille recomposée peut être mal représentée ; l’ingénieur patrimonial risque de devoir retraiter manuellement les informations ensuite.

/espace-ingenieur/modifications

Problème : À l’étape 3 – Collecte et analyse documentaire, l’ingénieur patrimonial doit configurer la collecte documentaire à partir des informations déjà obtenues lors de l’entretien initial et dans le DCI complet. Actuellement, depuis cet écran, il ne semble pas disposer d’un accès direct au DCI complet du foyer concerné. Il ne peut donc ni : le consulter facilement depuis la page de configuration ; ni, à défaut, le télécharger directement depuis cet écran. Cela oblige l’ingénieur patrimonial à configurer la collecte en se reposant sur sa mémoire ou à quitter la page pour aller rechercher les informations ailleurs. Ce fonctionnement est peu compatible avec l’objectif d’une plateforme centralisée dans laquelle les informations et documents du dossier doivent rester accessibles sans créer de dossier parallèle à l’extérieur de l’outil.

Attendu : Ajouter depuis l’écran de configuration de la collecte documentaire un accès permanent et rapide au DCI complet du foyer concerné. La solution la plus pratique serait de proposer un volet latéral consultable sans quitter la page, par exemple à droite ou à gauche de l’écran. L’ingénieur patrimonial pourrait ainsi : ouvrir le DCI complet ; consulter les réponses déjà fournies par le foyer ; naviguer dans ses différentes rubriques ; refermer le volet et poursuivre immédiatement la configuration de la collecte. L’objectif est de permettre une consultation en parallèle de la configuration, sans changement de page ni perte de contexte. À défaut d’un volet latéral, un bouton clairement visible du type : « Consulter le DCI complet » pourrait ouvrir le document dans une fenêtre ou un panneau dédié. Un accès au téléchargement peut également être conservé si nécessaire, mais la consultation directe dans la plateforme doit être privilégiée. Comportement attendu Depuis la page de configuration de la collecte : l’ingénieur clique sur « Consulter le DCI complet » ; le DCI complet du dossier actuellement ouvert s’affiche ; il peut consulter les informations sans quitter sa configuration ; il ferme le volet ou la fenêtre ; il retrouve exactement l’état de sa collecte ; aucune réponse ni sélection déjà effectuée n’est perdue. Le document affiché doit naturellement être celui du bon foyer, avec les deux membres du couple lorsqu’il s’agit d’un dossier couple. Principe général à respecter Les documents et informations déjà recueillis au cours du parcours doivent rester directement accessibles depuis les étapes où ils sont nécessaires au travail de l’ingénieur patrimonial. La plateforme doit éviter de contraindre l’ingénieur à : télécharger des documents pour les stocker localement ; constituer un dossier parallèle sur son ordinateur ; naviguer entre plusieurs pages simplement pour vérifier une information déjà présente dans le dossier.

Intention : Permettre à l’ingénieur patrimonial de configurer la collecte documentaire en s’appuyant en temps réel sur les informations déjà déclarées dans le DCI complet, tout en conservant l’ensemble du travail dans ASTRAEOS. L’objectif est de faire de la plateforme le point central de consultation et de traitement du dossier patrimonial, sans dépendance à des dossiers ou pièces stockés en dehors de l’outil.

Gêne : En l’état : l’ingénieur doit configurer la collecte sans avoir sous les yeux les informations détaillées déjà renseignées ; il peut oublier ou mal interpréter une donnée ; il doit interrompre son travail pour rechercher le DCI ailleurs ; cela favorise la création de dossiers ou téléchargements externes ; cela réduit fortement l’intérêt d’une collecte documentaire centralisée sur la plateforme.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, l’en-tête de la page affiche uniquement le nom du premier membre du foyer : Tristan LANGLOIS alors que le dossier concerne un couple depuis le début du parcours. Le conjoint, partenaire ou concubin n’apparaît pas dans cet en-tête, alors même que : le foyer a été identifié comme un couple dès l’étape Prospect ; les deux personnes ont été rattachées au même dossier ; chacune a rempli son questionnaire de qualification ; l’étude patrimoniale porte sur l’ensemble du foyer. L’affichage donne donc l’impression que la collecte documentaire ne concerne qu’une seule personne.

Attendu : Lorsque le dossier concerne un couple, l’en-tête de l’étape 3 doit reprendre les identités des deux membres du foyer. Par exemple : Tristan LANGLOIS & Sarah PABOIS ou selon la convention graphique retenue dans les autres écrans ASTRAEOS : Tristan LANGLOIS et Sarah PABOIS Les identités doivent être récupérées automatiquement depuis le dossier du foyer, sans nouvelle saisie. Si le dossier concerne une personne seule, une seule identité doit naturellement être affichée. Principe général à respecter L’identité affichée à chaque étape du parcours doit refléter le périmètre réel du dossier patrimonial. Lorsqu’une étude concerne un couple, les interfaces communes au foyer ne doivent pas laisser penser qu’elles sont rattachées uniquement au premier membre du couple. Cette cohérence doit être maintenue entre : Prospect ; Conformité ; Collecte et analyse documentaire ; Études en cours ; Études restituées ; et les autres écrans de suivi du dossier.

Intention : Maintenir une représentation cohérente du foyer étudié tout au long du parcours patrimonial et éviter toute ambiguïté sur les personnes concernées par la collecte documentaire et l’étude.

Gêne : En l’état : l’ingénieur peut avoir l’impression que la collecte est rattachée uniquement au premier membre du couple ; cela crée une rupture de cohérence avec les étapes précédentes ; cela peut faire naître un doute sur le bon rattachement des informations et documents du conjoint ; l’interface ne reflète pas correctement le fait que l’étude est réalisée pour l’ensemble du foyer.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Identité et situation familiale », l’ingénieur patrimonial peut renseigner le champ « Mesure de protection ». Lorsque l’ingénieur connaît déjà l’information et sélectionne une mesure de protection, le moteur ajoute des documents relatifs à cette mesure. Ce fonctionnement est cohérent : il n’est pas nécessaire de redemander au client si une mesure existe lorsque l’information est déjà connue. En revanche, lorsque l’ingénieur ne dispose pas de l’information et laisse le champ sur : « À confirmer » aucune question n’est ajoutée aux éléments à collecter auprès du client. La collecte ne permet donc pas de déterminer : s’il existe ou non une mesure de protection au sein du foyer ; et, le cas échéant, de quel type de mesure il s’agit. Par ailleurs, en consultant les questions non incluses de la section « Identité et situation familiale », aucune question relative aux mesures de protection n’est disponible. La question conditionnelle semble donc ne pas exister actuellement dans le référentiel de collecte.

Attendu : Le comportement doit dépendre de l’état renseigné par l’ingénieur patrimonial. Si l’ingénieur connaît déjà l’existence et le type de mesure de protection : ne pas redemander au client si une mesure existe ; ne pas redemander le type si celui-ci est déjà connu ; ajouter uniquement les documents pertinents relatifs à la mesure identifiée. Si l’ingénieur indique qu’il n’existe aucune mesure de protection : ne poser aucune question complémentaire au client ; ne demander aucun document relatif à une mesure de protection. Si le champ reste sur « À confirmer » : une question doit automatiquement apparaître dans les éléments à collecter auprès du client, par exemple : « Une mesure de protection concerne-t-elle actuellement une personne du foyer ? » Si le client répond Non : aucune question supplémentaire ; aucun document relatif à une mesure de protection. Si le client répond Oui : afficher une question complémentaire permettant de préciser le type de mesure de protection ; si nécessaire, identifier la personne du foyer concernée ; puis déclencher les documents correspondants à la mesure renseignée. Arborescence attendue Mesure de protection connue par l’ingénieur → ne pas redemander l’information → demander uniquement les documents pertinents. Aucune mesure connue et confirmée → aucune question ni document supplémentaire. À confirmer → « Une mesure de protection concerne-t-elle une personne du foyer ? » → Non : fin du chemin. → Oui : préciser la mesure et la personne concernée si nécessaire → demander les documents correspondants. Questions non incluses La question relative à l’existence d’une mesure de protection, ainsi que ses éventuelles sous-questions conditionnelles, doivent également exister dans le référentiel des éléments de collecte. Elles doivent donc pouvoir apparaître dans « Non incluses » lorsqu’elles ne sont pas sélectionnées par le moteur conditionnel. L’absence totale de cette question dans les éléments non inclus confirme actuellement qu’elle ne peut pas être activée lorsque l’information reste à recueillir.

Intention : Faire en sorte que l’état « À confirmer » remplisse réellement son rôle : lorsqu’une information n’est pas connue de l’ingénieur patrimonial, la collecte doit permettre de l’obtenir auprès du client. L’objectif est également d’éviter les doublons : une information déjà connue de l’ingénieur ne doit pas être redemandée, tandis qu’une information inconnue doit pouvoir être collectée avec les bonnes questions et les bons documents conditionnels.

Gêne : En l’état, une information importante peut rester totalement non qualifiée : l’ingénieur ne connaît pas la réponse ; il laisse « À confirmer » ; aucune question n’est adressée au client ; aucune information supplémentaire ne permettra ensuite de déterminer s’il existe une mesure de protection. La collecte peut donc être considérée comme complète alors qu’un élément de situation familiale reste en réalité non renseigné.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Titre du ticket Reprendre les informations du DCI complet et rendre conditionnelles les questions relatives aux enfants adoptés ou décédés Problème / demande À l’étape 3 – Collecte et analyse documentaire, dans la section « Identité et situation familiale », l’ingénieur patrimonial doit actuellement renseigner manuellement : « Un enfant est-il adopté ? » « Un enfant est-il décédé ? » Deux problèmes apparaissent. D’une part, ces informations ont vocation à être déjà connues lorsqu’elles ont été renseignées dans le DCI complet. Elles ne devraient donc pas nécessiter une nouvelle saisie par l’ingénieur patrimonial. D’autre part, lorsque l’ingénieur répond Non à ces questions, les éléments à collecter dans la partie droite continuent à proposer : « L’enfant est-il adopté ? » « L’enfant est-il décédé ? » La réponse apportée lors de la configuration de la collecte n’est donc pas correctement prise en compte.

Attendu : 1. Reprendre automatiquement les données du DCI complet Lorsque l’information existe dans le DCI complet, elle doit préremplir automatiquement la configuration de la collecte. Par exemple : Un enfant est-il adopté ? → Non Un enfant est-il décédé ? → Non L’ingénieur ne doit pas avoir à ressaisir une information déjà collectée auprès du foyer. Si le DCI complet permet également d’identifier quel enfant est concerné, cette identité doit elle aussi être reprise. 2. Si la réponse est « Non » Lorsque la réponse est Non : la question correspondante doit disparaître des éléments à collecter auprès du client ; les éventuelles pièces documentaires exclusivement liées à cette situation doivent également être retirées. Exemple : Un enfant est-il adopté ? → Non ⇒ ne plus demander au client si un enfant est adopté. Même logique pour le décès d’un enfant. 3. Si la réponse est « Oui » Si la réponse est Oui, il ne faut pas simplement redemander : « L’enfant est-il adopté ? » puisque cette information est déjà connue. Il faut uniquement recueillir l’information complémentaire encore manquante, par exemple : « Quel enfant est concerné ? » Cette sélection doit reprendre les identités des enfants déjà enregistrés dans le foyer, notamment lorsqu’il y en a plusieurs. Même fonctionnement pour un enfant décédé : « Un enfant est-il décédé ? » → Oui puis, uniquement si l’identité n’est pas déjà connue : « Quel enfant est concerné ? » Les éventuels documents liés à l’adoption ou au décès doivent ensuite être déclenchés uniquement lorsque la situation le justifie. 4. Si l’information du DCI complet est absente ou incomplète Si le DCI complet ne permet pas de déterminer la réponse, la question peut rester « À confirmer ». Dans ce cas, la collecte client doit fonctionner ainsi : « Un enfant est-il adopté ? » → Non : aucune autre question ni pièce sur ce sujet. → Oui : demander quel enfant est concerné. Même logique pour le décès. Principe général à respecter La priorité doit être : information déjà présente dans le DCI complet → reprise automatique → ne demander au client que ce qui manque réellement. Il ne faut ni obliger l’ingénieur à ressaisir l’information, ni la redemander ensuite au client.

Intention : Réutiliser réellement les informations déjà collectées dans le DCI complet et rendre la collecte documentaire plus ciblée. L’objectif est d’éviter les doubles saisies par l’ingénieur et de ne demander au client que les précisions qui restent nécessaires, notamment l’identité de l’enfant concerné lorsque plusieurs enfants composent le foyer.

Gêne : En l’état : l’ingénieur doit ressaisir des informations déjà présentes dans le DCI complet ; une réponse Non ne supprime pas la question correspondante côté client ; une réponse Oui conduit à poser de nouveau une question déjà résolue au lieu de demander uniquement l’information complémentaire utile ; la logique devient particulièrement ambiguë lorsqu’il existe plusieurs enfants dans le foyer.

/espace-ingenieur/profil

Problème : La signature et le profil affichent actuellement les initiales de l’ingénieur dans un cercle, sans possibilité de remplacer cet élément par une photographie.

Attendu : Permettre à l’ingénieur de télécharger une photo de profil. Prévoir un module simple permettant de recadrer la photo, de la repositionner et de vérifier son rendu avant validation. Définir des dimensions et une résolution minimales afin de garantir un affichage de qualité. La photographie pourrait ensuite remplacer les initiales dans le cercle prévu à cet effet.

Intention : Permettre une personnalisation plus professionnelle et plus humaine du profil et de la signature.

Gêne : Les initiales sont fonctionnelles mais impersonnelles. Pour une activité de conseil reposant fortement sur la relation humaine, une photographie permet d’identifier plus facilement l’interlocuteur et de renforcer la cohérence entre le profil, les communications et la page publique de prise de rendez-vous.

/espace-ingenieur/profil

Problème : Le champ actuellement intitulé « Contact » correspond en réalité à une adresse email et le numéro de téléphone n’est pas prévu.

Attendu : Renommer « Contact » en « Email » et ajouter un champ « Téléphone ». Le numéro doit respecter la règle générale de présentation retenue sur la plateforme, avec séparation des chiffres pour améliorer la lisibilité.

Intention : Permettre de construire une signature professionnelle complète avec des coordonnées immédiatement identifiables.

Gêne : Le terme « Contact » est imprécis et l’absence de téléphone limite l’utilité de la signature pour les destinataires des emails.

/espace-ingenieur/profil

Problème : La fenêtre d’édition de la signature comporte une croix de fermeture en haut à droite alors qu’un bouton « Annuler » est déjà prévu en bas de la fenêtre.

Attendu : Supprimer la croix et conserver un seul mode explicite de sortie sans sauvegarde : le bouton « Annuler ».

Intention : Éviter la multiplication des actions ayant exactement la même fonction.

Gêne : Deux mécanismes différents pour fermer la même fenêtre créent une redondance inutile et peuvent laisser planer un doute sur le comportement respectif de la croix et du bouton « Annuler ».

/espace-ingenieur/profil

Problème : Dans le titre « Modifier la signature », les deux parties utilisent actuellement des traitements typographiques ou des couleurs différentes.

Attendu : Afficher l’ensemble du titre dans une seule police, une seule taille et une seule couleur, idéalement le bleu utilisé pour les autres titres de la plateforme.

Intention : Conserver une hiérarchie graphique simple et cohérente dans toutes les fenêtres modales.

Gêne : Les différences de traitement au sein d’un même titre donnent l’impression que les mots ont des niveaux d’importance différents alors qu’ils constituent un seul intitulé.

/espace-ingenieur/profil

Problème : Dans la fenêtre d’édition de la signature, le texte « Personnalisez le bloc inséré au bas de vos emails. Les mentions réglementaires restent sous votre responsabilité » paraît inutilement descriptif.

Attendu : Supprimer ce texte ou, si une information réglementaire doit absolument être conservée, la placer dans une infobulle dédiée.

Intention : Alléger la fenêtre d’édition pour donner immédiatement accès aux champs utiles.

Gêne : L’utilisateur comprend déjà qu’il se trouve dans l’édition de sa signature. Ce texte occupe de l’espace et alourdit une fenêtre qui peut être beaucoup plus directe.

/espace-ingenieur/profil

Problème : Certaines informations du profil, notamment l’identité, les coordonnées professionnelles ou les agréments réglementaires, ne doivent pas pouvoir être modifiées directement par l’ingénieur.

Attendu : Lorsqu’un pictogramme d’édition est volontairement désactivé, afficher au survol un message du type : « Cette information est administrée par votre cabinet. Contactez votre référent ASTRAEOS pour la modifier. »

Intention : Expliquer immédiatement pourquoi une action est indisponible et orienter l’utilisateur vers le bon interlocuteur.

Gêne : Un bouton simplement désactivé peut être interprété comme un bug ou une fonctionnalité momentanément indisponible. L’utilisateur ne sait pas comment procéder pour corriger son information.

/espace-ingenieur/profil

Problème : Plusieurs blocs présentent d’importantes zones vides, notamment « Formation & compétences » et la zone de signature email.

Attendu : Repenser la disposition et la hauteur des différents blocs afin qu’ils s’adaptent davantage à leur contenu. Réorganiser éventuellement l’ordre ou la largeur des blocs pour limiter les grands espaces inutilisés, tout en conservant une mise en page aérée.

Intention : Créer une page plus compacte, équilibrée et agréable à parcourir.

Gêne : Les grands espaces vides allongent artificiellement la page, obligent à davantage faire défiler l’écran et donnent une impression de mise en page inachevée.

/espace-ingenieur/profil

Problème : La rubrique Signature email utilise encore un bouton textuel « Modifier », alors que les actions d’édition sont progressivement harmonisées sur la plateforme.

Attendu : Remplacer « Modifier » par le seul pictogramme crayon, avec éventuellement une infobulle « Modifier la signature » au survol.

Intention : Généraliser une même convention graphique pour toutes les actions d’édition.

Gêne : La coexistence de boutons textuels et de pictogrammes pour une action identique rend l’interface moins homogène et visuellement plus lourde.

/espace-ingenieur/profil

Problème : Les boutons « Annuler » et « Fermer » apparaissent en haut de la page Profil & agréments alors qu’aucune modification globale de la page ne semble être en cours.

Attendu : Supprimer ces deux boutons. Les actions d’enregistrement ou d’annulation doivent uniquement apparaître lorsqu’une modification spécifique est réellement engagée.

Intention : Réserver les boutons d’action aux situations dans lesquelles une action utilisateur est effectivement attendue.

Gêne : Leur présence laisse penser qu’une modification générale est en cours ou qu’il faut fermer la page, alors qu’il s’agit simplement d’une page de consultation.

/espace-ingenieur/profil

Problème : Le bandeau du profil affiche « Compte actif & conforme » ainsi que la date et l’heure de dernière connexion.

Attendu : Supprimer ces deux informations de cet écran. Si le statut du compte doit être supervisé, cette information doit relever d’un espace d’administration accessible au cabinet ou aux administrateurs.

Intention : Ne conserver dans le profil de l’ingénieur que les informations qui lui sont directement utiles.

Gêne : Ces informations n’appellent aucune action de la part de l’ingénieur et occupent inutilement une place importante dans une zone très visible de la page.

/espace-ingenieur/profil

Problème : Les rappels de rendez-vous semblent actuellement prédéfinis, par exemple 24 heures avant puis 1 heure avant, sans possibilité évidente de personnalisation.

Attendu : Permettre à chaque ingénieur de définir ses propres délais de rappel pour chaque canal. Par exemple : 48 h, 24 h, 1 h, 15 min, 10 min, ou aucun rappel.

Intention : Permettre à chacun d’adapter les rappels à son organisation et à sa manière de travailler.

Gêne : Un paramétrage unique ne correspond pas nécessairement aux pratiques de tous les ingénieurs et peut générer des rappels trop précoces, trop tardifs ou inutilement nombreux.

/espace-ingenieur/profil

Problème : La rubrique « Préférences de notifications » permet d’activer des notifications ASTRAEOS alors qu’aucun espace de notification ou pictogramme de type cloche ne semble actuellement disponible dans l’interface.

Attendu : Vérifier le canal réel associé à chaque préférence. Si des notifications internes ASTRAEOS sont prévues, créer un centre de notifications clairement accessible depuis l’interface, par exemple via une cloche. À défaut, ne proposer que les canaux réellement disponibles.

Intention : Faire correspondre les préférences proposées avec des fonctionnalités effectivement accessibles à l’utilisateur.

Gêne : L’utilisateur peut activer une notification sans savoir où ni comment elle lui sera adressée, ce qui rend le paramétrage difficile à comprendre et potentiellement inopérant.

/espace-ingenieur/profil

Problème : les différentes rubriques du profil ne présentent pas de manière homogène la possibilité de modifier les informations. par ailleurs, dans la rubrique « agréments réglementaires », l’intitulé est répété une seconde fois à l’intérieur du bloc, avec deux mentions redondantes « à compléter » et « à renseigner ».

Attendu : prévoir, dans chaque bloc susceptible d’être modifié, une action représentée uniquement par un pictogramme « crayon », sans texte associé. dans « agréments réglementaires » : supprimer la répétition de l’intitulé « agréments réglementaires » dans le contenu du bloc ; supprimer les mentions redondantes « à compléter » et « à renseigner ». pour les informations qui ne peuvent pas être modifiées directement par l’ingénieur, notamment l’identité personnelle et les agréments réglementaires, conserver éventuellement le pictogramme de modification mais dans un état désactivé/non cliquable.

Intention : harmoniser les actions d’édition sur toute la page tout en distinguant clairement les informations modifiables directement de celles qui nécessitent l’intervention du cabinet.

Gêne : Aujourd’hui, l’utilisateur ne sait pas immédiatement quelles données il peut modifier lui-même et lesquelles nécessitent l’intervention du cabinet. Les différents libellés et statuts ajoutent en outre de la complexité visuelle inutile.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, l’ingénieur patrimonial configure progressivement la collecte documentaire à partir de la colonne de gauche et des éléments générés dans la colonne de droite. Cette configuration peut être longue, puisqu’elle implique notamment : de répondre aux différentes questions de configuration ; de faire évoluer les questions à poser au client ; d’ajouter ou retirer des documents à demander ; de vérifier les différentes sections de la collecte ; d’ajuster manuellement les éléments présélectionnés par le moteur conditionnel. Actuellement, si l’ingénieur patrimonial quitte la page avant d’avoir terminé la préparation de la collecte, puis revient ultérieurement, la configuration repart à zéro. Les réponses renseignées, les sélections réalisées et les ajustements effectués ne sont pas conservés. Cela oblige l’ingénieur à recommencer entièrement la préparation de la collecte.

Attendu : Mettre en place une sauvegarde dynamique et persistante de la configuration de la collecte documentaire. Chaque modification effectuée par l’ingénieur doit être sauvegardée automatiquement, notamment : réponses Oui / Non / À confirmer ; sélections dans les listes déroulantes ; ajout ou retrait manuel de questions ; ajout ou retrait de documents ; ajustement des éléments présélectionnés ; état des différentes sections ; toute autre modification ayant un impact sur la composition de la collecte. La sauvegarde doit intervenir sans nécessiter de bouton spécifique de type « Enregistrer ». Reprise de la collecte Lorsque l’ingénieur patrimonial revient ultérieurement sur la configuration de la collecte, il doit retrouver exactement l’état dans lequel il l’avait laissée. Doivent notamment être restaurés : les réponses déjà renseignées ; les questions sélectionnées ou retirées ; les documents sélectionnés ou retirés ; les choix manuels de l’ingénieur ; les compteurs correspondants ; la configuration conditionnelle issue de ces réponses. La réouverture de la collecte ne doit jamais relancer une configuration vierge tant qu’une préparation existe déjà pour le dossier. Sauvegarde en temps réel La sauvegarde devrait idéalement être effectuée après chaque modification significative. Par exemple : modification d’une réponse → recalcul du moteur conditionnel → sauvegarde du nouvel état. Il pourrait également être utile d’afficher un indicateur discret dans l’interface, du type : Enregistrement… puis Enregistré afin que l’ingénieur sache que ses modifications ont bien été persistées. Gestion des interruptions La sauvegarde doit fonctionner même si l’ingénieur : revient sur une autre page du dossier ; ferme l’onglet ; quitte la plateforme ; ferme son navigateur ; se reconnecte ultérieurement ; reprend la collecte depuis un autre moment de son parcours. Il ne doit pas être nécessaire d’aller jusqu’à l’étape « Destinataires » ou jusqu’à l’envoi de la collecte pour enregistrer le travail réalisé. Attention au moteur conditionnel La restauration doit reprendre l’état sauvegardé de la configuration, et non recalculer arbitrairement toute la collecte à partir d’un état initial. Lors de la reprise, il faut préserver : les choix explicites de l’ingénieur ; les exclusions manuelles ; les ajouts manuels ; les conséquences conditionnelles déjà validées. Si un recalcul est nécessaire techniquement, il ne doit pas écraser les modifications manuelles déjà sauvegardées. Comportement attendu L’ingénieur commence à configurer une collecte. Il renseigne plusieurs réponses et modifie les questions ou documents sélectionnés. Chaque modification est automatiquement sauvegardée. Il quitte la page avant d’avoir terminé. Il revient ultérieurement sur Collecte et analyse documentaire. La configuration reprend exactement là où elle avait été laissée. Aucun élément déjà configuré ne doit être perdu ou réinitialisé.

Intention : Permettre à l’ingénieur patrimonial de préparer une collecte documentaire en plusieurs sessions, sans risque de perdre le travail déjà réalisé. La configuration de la collecte peut être suffisamment longue et détaillée pour qu’il soit normal de devoir l’interrompre puis la reprendre. La plateforme doit donc traiter cette préparation comme un brouillon persistant du dossier, et non comme une session temporaire valable uniquement tant que la page reste ouverte.

Gêne : En l’état : tout travail effectué avant de quitter la page peut être perdu ; l’ingénieur doit recommencer la configuration depuis le début ; cela crée une perte de temps importante ; cela augmente le risque d’incohérences entre deux configurations successives ; l’ingénieur peut hésiter à interrompre son travail de peur de perdre les modifications ; la préparation d’une collecte volumineuse devient difficilement exploitable dans un usage réel. Ce dysfonctionnement est particulièrement bloquant compte tenu du nombre important de questions et documents à paramétrer.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », lorsque l’ingénieur patrimonial indique qu’un crédit immobilier est en cours, une question complémentaire apparaît dans la colonne de gauche : « Un remboursement ou une renégociation est-il envisagé ? » Actuellement, que l’ingénieur patrimonial réponde Oui ou Non, cela ne semble avoir aucun impact sur les questions ou les documents qui seront demandés au client dans la colonne de droite. La question est donc renseignable, mais la réponse n’est pas réellement exploitée par le moteur conditionnel.

Attendu : Cette question doit devenir un véritable déclencheur conditionnel de la collecte. Si l’ingénieur répond « Oui » : la collecte client doit permettre de préciser le projet, sans redemander la question générique déjà renseignée par l’ingénieur. Il pourrait notamment être demandé : s’agit-il d’un remboursement anticipé, d’une renégociation du prêt, d’un rachat de crédit ou d’un autre projet ; quel emprunt est concerné lorsqu’il en existe plusieurs ; à quel horizon le projet est envisagé ; éventuellement le montant de remboursement envisagé lorsqu’il est connu ; toute précision utile sur l’objectif recherché. Si le client dispose déjà d’un document lié à ce projet — par exemple une proposition bancaire ou une simulation — il peut être pertinent de pouvoir le demander. En revanche, aucune pièce ne doit être rendue artificiellement obligatoire si aucune démarche formalisée n’a encore été engagée. Si l’ingénieur répond « Non » : la question « Le client envisage-t-il un remboursement anticipé, une vente ou une renégociation ? » actuellement présente dans la colonne de droite ne doit plus être demandée au client pour le même sujet ; aucune question complémentaire relative à un remboursement ou une renégociation ne doit être ajoutée ; aucun document spécifique à un tel projet ne doit être demandé. Si l’ingénieur ne connaît pas la réponse et laisse l’état « À confirmer » : la question doit rester à recueillir auprès du client ; le moteur doit attendre sa réponse avant de déclencher les éventuelles précisions complémentaires. Attention à la formulation actuelle de la colonne de droite La question actuellement visible semble être formulée ainsi : « Le client envisage-t-il un remboursement anticipé, une vente ou une renégociation ? » Il conviendrait également de vérifier la cohérence entre les deux formulations. Dans la colonne de gauche, la question porte sur : remboursement ou renégociation alors que celle de droite ajoute également : vente Or le projet de vente du logement fait déjà l’objet d’une question distincte dans la partie Immobilier. Il serait donc préférable de ne pas mélanger le projet de vente du bien avec le projet de remboursement ou de renégociation du crédit, afin d’éviter les doublons et les déclenchements croisés. Principe général à respecter Une information déjà renseignée par l’ingénieur patrimonial lors de la configuration de la collecte ne doit pas être redemandée telle quelle au client. La logique attendue est : réponse de l’ingénieur → recalcul de la collecte → maintien uniquement des précisions encore nécessaires. Comportement attendu Lorsque l’ingénieur modifie cette réponse : la sous-rubrique Crédit immobilier se recalcule immédiatement ; la question redondante disparaît de la colonne de droite si l’information est déjà connue ; si la réponse est Oui, seules les précisions utiles sur le projet apparaissent ; si la réponse est Non, aucun élément spécifique au remboursement ou à la renégociation ne reste sélectionné ; si la réponse repasse à À confirmer, la question redevient à recueillir auprès du client ; les compteurs de questions et de pièces sont actualisés.

Intention : Faire en sorte que cette question serve réellement à personnaliser la collecte documentaire et à identifier uniquement les informations complémentaires nécessaires lorsqu’un projet de remboursement ou de renégociation existe. L’objectif est également d’éviter que l’ingénieur renseigne une information qui soit ensuite redemandée à l’identique au client, tout en conservant la possibilité de recueillir les détails du projet lorsque celui-ci est confirmé.

Gêne : En l’état : la réponse de l’ingénieur n’a aucune conséquence opérationnelle ; le client peut se voir redemander une information déjà qualifiée ; des questions peuvent rester sélectionnées alors qu’elles sont devenues inutiles ; le moteur conditionnel ne remplit pas son rôle d’allègement et de personnalisation de la collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », plusieurs questions très détaillées concernant les biens locatifs sont actuellement posées directement à l’ingénieur patrimonial dans la colonne de gauche. On retrouve notamment : le bien est-il actuellement loué ? le logement est-il soumis à l’encadrement des loyers ? une assurance loyers impayés couvre-t-elle le bien ? le bien est-il couvert par la garantie Visale ? la location est-elle meublée ? existe-t-il un bail commercial, professionnel ou notarié ? la gestion est-elle confiée à une agence ou une conciergerie ? etc. À ce stade du parcours, l’ingénieur patrimonial a réalisé l’entretien initial et dispose du DCI transmis par le client. Il ne dispose pas nécessairement de ce niveau de détail pour chacun des biens locatifs détenus. Ces informations relèvent précisément de la collecte complémentaire auprès du client, puis de l’analyse documentaire. Les demander à l’ingénieur dans la phase de configuration l’oblige soit à renseigner des éléments qu’il ne connaît pas, soit à laisser de nombreuses questions « À confirmer », ce qui détourne cette colonne de sa fonction.

Attendu : La colonne de gauche doit rester centrée sur les informations structurantes déjà connues ou raisonnablement qualifiables par l’ingénieur à partir de l’entretien et du DCI. Par exemple, il est pertinent d’y conserver une question générale comme : « Le foyer détient-il de l’immobilier locatif ? » En revanche, dès lors que la réponse est Oui, les caractéristiques détaillées de chaque bien doivent être recueillies directement auprès du client dans la colonne de droite. Pour chaque bien locatif concerné, la collecte client doit notamment pouvoir demander, selon les besoins : le bien est-il actuellement loué ou vacant ? quel est le type de location ? quel est le type de bail ? le bien est-il soumis à un dispositif d’encadrement des loyers ? existe-t-il une assurance loyers impayés ? existe-t-il une garantie Visale ? la gestion est-elle confiée à une agence, un administrateur de biens ou une conciergerie ? les autres caractéristiques nécessaires à l’analyse locative. Mettre en place une logique conditionnelle côté client Ces questions ne doivent pas toutes apparaître indistinctement. La collecte doit fonctionner par arborescence. Exemples : Bien actuellement loué = Non → ne pas poser les questions relatives au bail en cours, au loyer pratiqué ou aux garanties attachées au locataire actuel. Gestion confiée à un professionnel = Oui → demander les précisions utiles et, si pertinent, les documents de gestion. Garantie loyers impayés = Oui → demander les informations et documents relatifs au contrat. Garantie Visale = Oui → demander le justificatif correspondant. Location meublée = Oui → déclencher uniquement les questions pertinentes pour ce mode d’exploitation. Type de bail concerné → adapter les questions et documents à demander en conséquence. L’objectif est que la réponse du client déclenche les précisions et pièces nécessaires, plutôt que de demander à l’ingénieur de connaître ces informations avant même la collecte documentaire. Gestion de plusieurs biens Cette logique doit fonctionner bien par bien. Si le foyer détient plusieurs biens locatifs, chaque actif doit pouvoir disposer de ses propres caractéristiques et déclencheurs. Il ne faut pas qu’une réponse concernant un premier logement soit appliquée indistinctement à l’ensemble du patrimoine locatif. Principe général à appliquer sur l’ensemble de la collecte Cette correction ne doit pas être pensée uniquement pour les quelques questions visibles sur la capture. Il faut conserver une distinction claire entre : 1. Configuration par l’ingénieur patrimonial Informations structurantes déjà connues grâce à l’entretien initial et au DCI, permettant de déterminer les grands thèmes à investiguer. 2. Collecte auprès du client Informations détaillées que l’ingénieur n’a pas nécessairement en sa possession et qui doivent être précisées par le client. 3. Analyse documentaire ultérieure Informations précises qui seront vérifiées ou extraites des baux, contrats, avis, relevés, actes et autres documents transmis. Cette logique doit être respectée dans toutes les sections de la collecte documentaire, et pas uniquement dans l’immobilier locatif. L’ingénieur ne doit pas être transformé en intermédiaire chargé de préremplir des informations détaillées qu’il cherche précisément à obtenir grâce à la collecte.

Intention : Clarifier le rôle de chacun dans le processus : l’ingénieur configure les sujets à investiguer ; le client apporte les informations détaillées qu’il connaît ; les documents permettent ensuite de vérifier et compléter ces informations. L’objectif est de rendre la configuration de la collecte plus rapide et réaliste pour l’ingénieur, tout en utilisant le moteur conditionnel pour construire un questionnaire client précis et adapté à chaque bien.

Gêne : En l’état : l’ingénieur est interrogé sur des informations qu’il ne possède pas nécessairement ; la colonne de gauche devient inutilement longue et détaillée ; il existe un risque de réponses approximatives ; les mêmes informations devront de toute façon être confirmées par le client ou retrouvées dans les documents ; la répartition des rôles entre configuration de la collecte et collecte client devient confuse.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, l’ingénieur patrimonial configure la collecte documentaire à partir des questions présentes dans la colonne de gauche. Pour chaque question, il peut généralement répondre Oui ou Non. Ces réponses ont ensuite un impact direct sur la colonne de droite et peuvent : ajouter ou supprimer des questions à poser au client ; ajouter ou supprimer des documents à demander ; modifier les sous-rubriques qui seront intégrées à la collecte. Actuellement, une fois que l’ingénieur patrimonial a sélectionné Oui ou Non, il n’existe pas de possibilité de revenir à l’état initial « À confirmer ». Cela pose problème si l’ingénieur : s’est trompé en sélectionnant une réponse ; se rend compte qu’il ne dispose finalement pas d’une information suffisamment fiable ; souhaite laisser cette information à confirmer directement auprès du client. Une réponse potentiellement erronée peut donc continuer à modifier la configuration de la collecte sans possibilité de revenir à un état neutre.

Attendu : Pour chaque question conditionnelle de la colonne de gauche, l’ingénieur patrimonial doit pouvoir sélectionner trois états distincts : Oui Non À confirmer L’état « À confirmer » doit correspondre à l’absence de réponse certaine de l’ingénieur. Il doit être possible de passer librement : Oui → À confirmer Non → À confirmer À confirmer → Oui À confirmer → Non Oui → Non Non → Oui sans devoir réinitialiser la page ou recréer la collecte. Comportement attendu de l’état « À confirmer » Lorsqu’une question repasse à « À confirmer » : la réponse précédemment donnée par l’ingénieur est supprimée ; le moteur conditionnel doit recalculer immédiatement la collecte ; les questions nécessaires à la qualification du sujet doivent réapparaître côté client ; les documents ne doivent être demandés que selon la logique applicable à une information non encore confirmée ; les compteurs de questions et de pièces doivent être actualisés. Exemple : « Le foyer a-t-il un crédit immobilier en cours ? » Si l’ingénieur avait répondu Non, puis se rend compte qu’il n’en est pas certain, il doit pouvoir repasser la question en « À confirmer ». La collecte doit alors se comporter comme si aucune réponse fiable n’avait encore été apportée par l’ingénieur et permettre de recueillir l’information auprès du client. Présentation proposée Le fonctionnement actuel peut être conservé visuellement, avec l’ajout d’un troisième choix explicite. Par exemple : Oui | Non | À confirmer ou, si l’interface doit rester compacte : Oui Non un bouton / état neutre « À confirmer » L’état sélectionné doit être immédiatement identifiable. Principe général à respecter « À confirmer » ne doit pas être traité comme une réponse négative. Il signifie : l’information n’est pas suffisamment établie et doit encore être recueillie ou vérifiée. Cette distinction est importante pour éviter que l’absence d’information soit interprétée comme un Non et conduise à supprimer à tort des questions ou des documents nécessaires. Périmètre Cette fonctionnalité ne doit pas être limitée à la section Immobilier visible sur la capture. Elle doit être disponible pour l’ensemble des questions Oui / Non de la colonne de gauche, dans toutes les sections de préparation de la collecte, notamment : Identité et situation familiale ; Budget ; Fiscalité ; Patrimoine professionnel ; Immobilier ; Actifs financiers ; et toutes les autres rubriques utilisant le même moteur conditionnel.

Intention : Permettre à l’ingénieur patrimonial de corriger facilement une réponse ou de reconnaître explicitement qu’une information reste incertaine, sans fausser la composition de la collecte. L’objectif est de préserver la logique fondamentale du parcours : une information confirmée par l’ingénieur peut être utilisée pour alléger la collecte ; une information incertaine doit rester à confirmer auprès du client.

Gêne : En l’état : une erreur de clic peut modifier durablement la collecte ; l’ingénieur peut être obligé de conserver une réponse qu’il ne considère plus comme fiable ; des questions ou documents peuvent être supprimés à tort ; il n’existe pas de distinction opérationnelle entre « je sais que la réponse est Non » et « je ne sais pas encore ». Cette absence d’état neutre fragilise directement la fiabilité du moteur conditionnel.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », pour le logement d’usage du foyer, l’ingénieur patrimonial peut répondre à la question : « Une vente de ce logement est-elle envisagée ? » Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne modifie pas la colonne de droite. La question suivante reste systématiquement sélectionnée dans les informations à recueillir auprès du client : « Le client envisage-t-il de vendre ce bien ? » Il s’agit pourtant de la même information. Une fois la réponse apportée par l’ingénieur patrimonial, elle ne doit plus être redemandée au client.

Attendu : La réponse de l’ingénieur patrimonial doit alimenter directement le moteur conditionnel. Si l’ingénieur répond « Oui » : supprimer de la collecte la question générique « Le client envisage-t-il de vendre ce bien ? » ; faire éventuellement apparaître uniquement les précisions encore nécessaires sur le projet de vente, par exemple : horizon ou date envisagée ; raison ou contexte de la vente, si utile ; éventuel projet associé à la cession. Si l’ingénieur répond « Non » : supprimer également la question « Le client envisage-t-il de vendre ce bien ? » ; ne pas ajouter de questions complémentaires spécifiques à une vente. Si l’ingénieur ne répond pas : la question doit rester dans les éléments à recueillir auprès du client. Principe général à respecter Le questionnaire de qualification renseigné par l’ingénieur doit servir à éviter les doublons. La logique attendue est : information déjà renseignée par l’ingénieur = ne pas la redemander au client ; seules les précisions encore manquantes doivent subsister. Cette règle doit s’appliquer aussi bien à une réponse Oui qu’à une réponse Non. Comportement attendu Lorsque l’ingénieur modifie la réponse : la rubrique Logement d’usage se recalcule immédiatement ; la question redondante disparaît de la colonne de droite ; si la réponse est Oui, seules les éventuelles précisions utiles sont ajoutées ; si la réponse est Non, aucun élément relatif à un projet de vente ne reste sélectionné ; les compteurs de questions sélectionnées sont mis à jour.

Intention : Faire en sorte que les réponses apportées par l’ingénieur patrimonial soient réellement utilisées pour personnaliser et alléger la collecte client, en évitant de poser deux fois la même question. L’objectif est que le client ne soit interrogé que sur les informations qui restent effectivement à connaître.

Gêne : En l’état : l’ingénieur répond à la question ; le moteur n’en tient pas compte ; le client se voit ensuite poser exactement la même question. Cela crée une collecte redondante et donne l’impression que les réponses saisies dans la colonne de gauche n’ont pas d’effet réel sur la composition de la collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : Titre du ticket Rendre conditionnelles les questions « Les travaux sont-ils facturés ? » et « Les travaux ont-ils été déduits fiscalement ? » Problème / demande À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », lorsque l’ingénieur patrimonial indique que des travaux ont été réalisés sur le logement, deux questions complémentaires apparaissent dans la colonne de gauche : « Les travaux sont-ils facturés ? » « Les travaux ont-ils été déduits fiscalement ? » Actuellement, les réponses apportées à ces deux questions ne semblent pas réellement modifier la collecte située dans la colonne de droite. Sur la capture, l’ingénieur patrimonial a notamment répondu Non aux deux questions. Pourtant la sous-rubrique « Travaux » continue notamment à proposer : des informations relatives aux entreprises ayant réalisé les travaux ; la question « Ces dépenses ont-elles déjà été déduites de vos revenus imposables ? » ; et, plus généralement, des éléments qui devraient dépendre des réponses déjà renseignées par l’ingénieur.

Attendu : Les deux questions doivent devenir de véritables déclencheurs conditionnels de la collecte. 1. « Les travaux sont-ils facturés ? » Si Oui : conserver la possibilité de demander les factures de travaux disponibles ; conserver uniquement les informations complémentaires réellement nécessaires à leur analyse. Si Non : ne pas demander de factures de travaux ; ne pas demander des informations dont la seule finalité serait de reconstituer le détail figurant sur ces factures. En particulier, conformément à la simplification déjà demandée sur la rubrique Travaux, il n’est pas nécessaire de demander l’identité de chaque entreprise ayant réalisé chaque opération. L’information utile reste plutôt de savoir globalement si les travaux ont été réalisés par des professionnels et s’ils ont fait l’objet de factures. 2. « Les travaux ont-ils été déduits fiscalement ? » Si Oui : la collecte peut conserver ou faire apparaître les questions permettant de qualifier cette déduction, lorsqu’elles sont nécessaires à l’analyse fiscale. Les éventuels justificatifs fiscaux pertinents peuvent également être demandés selon la situation. Si Non : la question : « Ces dépenses ont-elles déjà été déduites de vos revenus imposables ? » ne doit plus être adressée au client puisqu’elle vient déjà d’être renseignée par l’ingénieur patrimonial. Aucun document spécifiquement destiné à justifier une déduction fiscale de ces travaux ne doit être demandé. Si aucune réponse n’est renseignée : l’information reste à recueillir auprès du client selon la logique générale de la collecte. Principe général à respecter Une réponse déjà qualifiée par l’ingénieur patrimonial ne doit pas être redemandée telle quelle au client. La logique attendue est donc : réponse de l’ingénieur → recalcul immédiat des questions et documents encore nécessaires → suppression des éléments devenus inutiles. Articulation avec la simplification de la rubrique Travaux Cette correction doit être mise en cohérence avec la demande précédente de simplification de la rubrique. Pour chaque bien, les informations réellement utiles doivent rester centrées sur : la nature des travaux ; leur montant total approximatif ; le fait qu’ils aient été réalisés par des professionnels et facturés ou non ; leur éventuelle déduction fiscale. Il n’est pas nécessaire de demander opération par opération : la date précise ; le montant de chaque opération ; l’identité de chaque entreprise. Comportement attendu Lorsque l’ingénieur modifie l’une de ces réponses : la sous-rubrique Travaux est recalculée immédiatement ; les questions déjà répondues disparaissent de la collecte client ; les documents devenus inutiles sont désélectionnés ; les documents nécessaires apparaissent uniquement lorsque les réponses le justifient ; les compteurs de questions et de pièces sont actualisés.

Intention : Faire en sorte que les réponses apportées par l’ingénieur patrimonial servent réellement à alléger et personnaliser la collecte, en évitant de redemander au client des informations déjà qualifiées ou de solliciter des justificatifs qui n’existent pas. L’objectif est également de recentrer la partie Travaux sur les informations réellement utiles à l’analyse patrimoniale et fiscale, sans demander au client un niveau de détail qui sera de toute façon retrouvé ultérieurement dans les documents disponibles.

Gêne : En l’état, l’ingénieur renseigne des informations qui n’ont pas de conséquence opérationnelle et le client risque ensuite : de devoir répondre une seconde fois à la même question ; de recevoir une demande de justificatifs inexistants ; ou de devoir fournir un niveau de détail inutilement important sur ses travaux.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », lorsque l’ingénieur patrimonial répond Oui à la question : « Des travaux ont-ils été réalisés sur ce logement ? » plusieurs questions apparaissent dans la sous-rubrique « Travaux ». Actuellement, cette sous-rubrique semble juxtaposer successivement : les questions relatives aux biens d’usage ; puis les questions relatives aux biens locatifs. La distinction n’est pas suffisamment visible. Cela donne l’impression que certaines questions sont posées deux fois alors qu’elles concernent en réalité deux catégories de biens différentes. Par ailleurs, le niveau de détail demandé sur les travaux est trop important pour la collecte patrimoniale. Certaines informations pourront être retrouvées ultérieurement lors de l’analyse documentaire et n’ont pas besoin d’être demandées au client à ce stade.

Attendu : La rubrique Immobilier doit distinguer très clairement quatre ensembles : 1. Travaux – biens d’usage Questions à recueillir auprès du client. 2. Documents relatifs aux travaux – biens d’usage Pièces à demander selon les réponses. 3. Travaux – biens locatifs Questions à recueillir auprès du client. 4. Documents relatifs aux travaux – biens locatifs Pièces à demander selon les réponses. Cette séparation doit être visible dans l’interface afin que l’ingénieur identifie immédiatement à quel patrimoine se rapporte chaque question ou chaque pièce. Simplifier les informations demandées sur les travaux Pour chaque bien concerné, les informations réellement utiles à ce stade sont principalement : la nature des travaux réalisés ; le montant total approximatif des travaux ; les travaux ont-ils été réalisés par une ou plusieurs entreprises et ont-ils fait l’objet de factures ? les dépenses ont-elles déjà été déduites fiscalement / des revenus imposables ?, lorsque cette question est pertinente. Il n’est pas nécessaire de demander au client le détail opération par opération. Questions à supprimer Les questions suivantes sont trop détaillées pour la collecte et peuvent être supprimées : « Description brève de chaque opération de travaux », si une qualification globale de la nature des travaux est déjà prévue ; « Date de réalisation de chaque opération » ; « Montant TTC de chaque opération », à remplacer par un montant total des travaux ; « Entreprise ayant réalisé chaque opération ». L’identité précise de chaque entreprise n’apporte pas de valeur suffisante à ce stade et pourra, si nécessaire, être retrouvée dans les factures lors de l’analyse documentaire. Questions à conserver / reformuler Pour chaque bien, conserver une logique simple du type : Des travaux ont-ils été réalisés sur ce bien ? Quelle était la nature principale des travaux ? Quel est le montant total approximatif des travaux ? Les travaux ont-ils été réalisés par une ou plusieurs entreprises et ont-ils fait l’objet de factures ? Ces dépenses ont-elles déjà été déduites fiscalement ? La nature des travaux pourrait être sélectionnée parmi plusieurs catégories, par exemple : construction ; reconstruction ; agrandissement ; amélioration ; réparation ; entretien ; autre à préciser. Documents à demander La demande documentaire doit également être conditionnelle. Si les travaux ont été réalisés par une ou plusieurs entreprises et ont fait l’objet de factures : demander les factures de travaux disponibles. Si la réponse est Non : ne pas demander artificiellement de factures inexistantes. Pour les biens locatifs, si les dépenses ont été fiscalement déduites, les justificatifs fiscaux ou comptables utiles peuvent rester demandés selon la logique générale de la collecte. Attention à la distinction usage / locatif Les règles doivent être appliquées séparément. Une réponse concernant les travaux réalisés sur le logement d’usage ne doit pas déclencher les questions relatives aux biens locatifs, et inversement. La structure attendue doit donc être lisible ainsi : Immobilier d’usage → Travaux → Questions → Documents Immobilier locatif → Travaux → Questions → Documents et non une seule rubrique « Travaux » regroupant successivement les deux catégories sans séparation claire.

Intention : Rendre la collecte : plus lisible pour l’ingénieur patrimonial ; moins redondante ; moins détaillée inutilement pour le client ; tout en conservant les informations réellement utiles à l’analyse patrimoniale et fiscale des travaux.

Gêne : En l’état : les travaux sur les biens d’usage et les biens locatifs semblent mélangés ; certaines questions donnent l’impression d’être présentes deux fois ; le client est interrogé opération par opération alors qu’un niveau d’information global suffit à ce stade ; des informations très précises comme la date ou l’identité de chaque entreprise alourdissent inutilement la collecte ; ces précisions pourront être retrouvées ultérieurement dans les factures et documents analysés par l’ingénieur.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », lorsque l’ingénieur patrimonial répond Oui à la question : « Le logement est-il détenu en indivision ? » le moteur ajoute automatiquement dans les documents à demander au client : « Convention d’indivision » Cette logique est trop automatique. Le fait qu’un bien soit détenu en indivision ne signifie pas nécessairement qu’une convention d’indivision a été conclue entre les indivisaires. La collecte risque donc de demander au client un document qui n’existe pas.

Attendu : La réponse Oui à : « Le logement est-il détenu en indivision ? » ne doit pas déclencher directement la demande de la convention d’indivision. Elle doit faire apparaître une question conditionnelle supplémentaire, par exemple : « Une convention d’indivision a-t-elle été établie pour ce bien ? » avec les réponses : Oui ; Non ; À confirmer / non renseigné selon le fonctionnement général du questionnaire. Logique conditionnelle attendue Si l’ingénieur répond Oui à l’existence d’une convention d’indivision : le document : Convention d’indivision doit être automatiquement ajouté aux pièces à demander au client. Si l’ingénieur répond Non : la convention d’indivision ne doit pas être demandée ; aucune pièce de ce type ne doit être présélectionnée. Si l’ingénieur ne connaît pas la réponse : la question : « Une convention d’indivision a-t-elle été établie pour ce bien ? » doit faire partie des informations à recueillir auprès du client. Si le client répond ensuite Oui, la convention d’indivision doit alors être demandée. S’il répond Non, aucune pièce ne doit être réclamée sur ce sujet. Arborescence attendue La logique serait donc : Le logement est-il détenu en indivision ? → Non : aucune question supplémentaire relative à une convention d’indivision. → Oui : afficher « Une convention d’indivision a-t-elle été établie ? » → Oui : demander la Convention d’indivision. → Non : ne pas demander ce document.

Intention : Distinguer correctement : le mode de détention du bien en indivision ; et l’existence éventuelle d’une convention organisant cette indivision. La collecte doit demander un document uniquement lorsqu’il existe réellement ou lorsque son existence reste à confirmer.

Gêne : En l’état, la seule qualification du bien comme détenu en indivision suffit à générer une demande documentaire supplémentaire. Cela : crée des demandes de pièces inexistantes ; oblige le client à chercher inutilement un document qu’il n’a jamais signé ; alourdit artificiellement la collecte ; et révèle une logique conditionnelle trop large entre la situation juridique du bien et les documents réellement disponibles.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », l’ingénieur patrimonial peut répondre à la question : « Le logement est-il détenu via une SCI ou une société ? » Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne semble avoir aucun impact sur les questions ni sur les documents demandés au client. La question est donc renseignable, mais elle n’est pas réellement exploitée dans le moteur conditionnel de collecte.

Attendu : Cette question doit devenir un véritable déclencheur conditionnel. Si l’ingénieur répond « Oui », la collecte doit permettre de qualifier le lien entre le bien immobilier et la société qui le détient, sans confondre pour autant l’analyse du bien avec l’analyse de la société. Il conviendrait notamment d’ajouter des questions permettant d’identifier : quelle société détient le bien ; si cette société est déjà connue dans le dossier ; quels membres du foyer détiennent des parts de cette société ; éventuellement si la détention est directe ou indirecte ; toute information utile pour rattacher correctement le bien à la société concernée. En revanche, les documents propres à l’analyse juridique ou financière de la société — statuts, répartition du capital, comptes sociaux, comptes courants d’associés, etc. — doivent rester gérés dans la section Patrimoine professionnel, et non dans Immobilier. Dans la section Immobilier, on doit continuer à demander uniquement les éléments utiles à l’analyse du bien lui-même, par exemple : acte ou titre relatif au bien ; valeur estimée ; taxe foncière ; charges de copropriété ; éléments relatifs à l’entretien ; financement éventuel attaché au bien ; autres documents propres à l’immeuble. Si l’ingénieur répond « Non » : les questions relatives à une détention via société doivent disparaître ; aucun document ou sous-question spécifique à ce mode de détention ne doit être ajouté. Si aucune réponse n’est apportée : l’information doit rester à recueillir ou à confirmer auprès du client. Point important de logique métier Le moteur doit bien distinguer : l’analyse du bien immobilier, qui reste dans la section Immobilier ; l’analyse de la société qui détient le bien, qui relève de la section Patrimoine professionnel. La réponse Oui à « Le logement est-il détenu via une SCI ou une société ? » doit donc servir à rattacher correctement le bien à une structure de détention, sans déplacer toute l’analyse immobilière dans la partie société. Comportement attendu L’ingénieur répond Oui, Non ou laisse la question sans réponse. La section Immobilier se recalcule immédiatement. Si Oui, les questions de qualification de la société détentrice apparaissent. Les documents immobiliers restent centrés sur le bien lui-même. Les documents sociétaires sont gérés dans Patrimoine professionnel. Si Non, les éléments spécifiques à la détention via société disparaissent. Les compteurs de questions et pièces sont actualisés.

Intention : Faire en sorte que cette question ait une réelle utilité dans la construction de la collecte et permette de représenter correctement les situations où un bien immobilier est détenu par une structure sociétaire.

Gêne : En l’état, l’ingénieur peut signaler qu’un bien est détenu via une SCI ou une société sans que cette information modifie la collecte. Cela peut conduire à : mal rattacher le bien à sa structure de détention ; ne pas identifier correctement les détenteurs indirects ; mélanger l’analyse immobilière et l’analyse sociétaire ; ou au contraire ne pas demander les éléments utiles pour comprendre la détention du bien.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », lorsque l’ingénieur patrimonial indique que le logement d’usage a été acheté, une question complémentaire apparaît : « L’acquisition est-elle passée par une agence ou un chasseur ? » Actuellement, que l’ingénieur patrimonial réponde Oui ou Non, cela ne semble avoir aucun impact sur les questions complémentaires ni sur les documents demandés au client. La question est donc renseignable mais n’est pas réellement exploitée dans la construction conditionnelle de la collecte.

Attendu : Cette question doit devenir un véritable déclencheur conditionnel. Si l’ingénieur répond « Oui », la collecte doit permettre de récupérer les informations utiles relatives à l’intermédiation lors de l’acquisition, par exemple : intervention d’une agence immobilière ou d’un chasseur immobilier ; éventuellement le montant des honoraires, s’il est connu ; toute précision utile sur ces frais d’acquisition lorsque nécessaire. Les documents pertinents liés à cette intervention doivent également pouvoir être demandés lorsqu’ils sont utiles à l’analyse, par exemple le justificatif ou la facture des honoraires correspondants si cette information n’est pas déjà suffisamment documentée dans les actes transmis. Si l’ingénieur répond « Non » : aucune question complémentaire relative à une agence ou à un chasseur ne doit être demandée ; aucun document spécifique à cette intermédiation ne doit être ajouté à la collecte. Si aucune réponse n’est apportée, l’information doit rester à recueillir auprès du client conformément à la logique générale de l’étape 3. Attention à la déduplication documentaire Si l’information ou les frais correspondants sont déjà suffisamment établis par un autre document demandé dans la collecte — par exemple l’acte d’acquisition ou un autre justificatif — il ne faut pas créer une demande documentaire redondante. Le moteur doit rechercher l’information utile, pas multiplier les pièces pour un même sujet. Comportement attendu L’ingénieur renseigne Oui, Non ou laisse la question sans réponse. La rubrique Immobilier est recalculée immédiatement. Si Oui, les éventuelles questions et pièces pertinentes apparaissent. Si Non, elles disparaissent. Si la réponse est supprimée, le sujet redevient à recueillir auprès du client. Les compteurs de questions et de pièces sont actualisés.

Intention : Faire en sorte que cette question ait une réelle utilité dans la préparation de la collecte et permette, lorsqu’une intermédiation a existé, de disposer des éléments nécessaires à l’analyse des conditions et coûts d’acquisition du bien.

Gêne : En l’état, l’ingénieur patrimonial peut renseigner une information sans qu’elle ait aucune conséquence sur la collecte. Cela crée une question sans utilité opérationnelle et rompt la logique annoncée du moteur conditionnel.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Immobilier », l’ingénieur patrimonial peut préciser le mode d’occupation du logement d’usage. Lorsque l’option : « Occupant à titre gratuit » est sélectionnée, une grande partie des questions relatives au logement d’usage disparaît, ainsi que les documents nécessaires à l’analyse du bien immobilier. Cette logique est trop restrictive. Le fait que le foyer occupe gratuitement un logement ne signifie pas que ce bien n’a pas à être analysé. Par exemple, le logement peut être détenu par une SCI familiale dont Monsieur et/ou Madame détiennent tout ou partie des parts. Dans ce cas, il faut bien distinguer deux analyses différentes : l’analyse de la société, qui relève de la partie Patrimoine professionnel ; l’analyse du bien immobilier lui-même, qui relève de la partie Immobilier.

Attendu : Le moteur doit distinguer : le mode d’occupation du logement ; le propriétaire juridique du bien ; le lien patrimonial éventuel du foyer avec ce propriétaire ; et surtout l’analyse du bien immobilier lui-même, qui reste nécessaire lorsqu’il entre dans le périmètre patrimonial du foyer. Lorsqu’un foyer est occupant à titre gratuit, il ne faut donc pas supprimer automatiquement les questions et documents relatifs au bien. Il faudrait d’abord qualifier la situation, par exemple avec une question : Qui détient le logement occupé par le foyer ? avec des choix du type : Monsieur / Madame directement ; le couple directement ; une société détenue totalement ou partiellement par le foyer ; un tiers sans lien patrimonial avec le foyer ; autre / à confirmer. Cas d’un bien détenu par une société du foyer Si le logement est détenu par une SCI familiale ou une autre société dont les clients détiennent tout ou partie des parts, deux analyses doivent coexister. 1. Analyse de la société – Patrimoine professionnel La société doit être analysée dans la rubrique Patrimoine professionnel, avec les éléments qui lui sont propres, par exemple : statuts ; répartition du capital ; comptes sociaux le cas échéant ; comptes courants d’associés ; organisation de la détention ; autres documents relatifs à la société. Ces documents ne doivent pas être demandés dans la rubrique Immobilier uniquement parce que la société détient le logement. 2. Analyse du bien – Immobilier Le bien immobilier lui-même doit continuer à être analysé dans la rubrique Immobilier, avec les informations et documents qui concernent directement l’immeuble, par exemple : adresse et identification du bien ; valeur de marché estimée ; taxe foncière ; charges de copropriété le cas échéant ; charges d’entretien ou autres charges significatives ; éventuel financement attaché au bien ; éléments utiles à sa valorisation ; documents relatifs au bien lui-même. L’analyse immobilière ne doit donc pas disparaître au seul motif que le foyer n’est pas directement propriétaire en nom propre. Si le foyer n’a aucun lien patrimonial avec le bien Si le foyer : est occupant à titre gratuit ; et le logement appartient réellement à un tiers extérieur au patrimoine du foyer ; sans détention directe ou indirecte par Monsieur ou Madame, alors il est logique d’alléger fortement la collecte immobilière concernant ce logement. Dans ce cas, seules les informations nécessaires pour comprendre la situation d’occupation doivent rester demandées. Point important de logique métier Le moteur ne doit pas appliquer : « Occupant à titre gratuit = pas d’analyse immobilière » Il doit appliquer une logique plus précise : « Occupant à titre gratuit = identifier qui détient le bien, puis déterminer s’il entre ou non dans le périmètre patrimonial du foyer. » Et si le bien est détenu par une société du foyer : la société est analysée dans Patrimoine professionnel, tandis que le bien est analysé séparément dans Immobilier. Les deux analyses sont complémentaires mais ne doivent pas être mélangées.

Intention : Éviter qu’un bien immobilier significatif disparaisse de l’analyse simplement parce que le foyer l’occupe gratuitement, tout en conservant une séparation claire entre : l’analyse juridique, capitalistique et financière de la société propriétaire ; l’analyse économique et patrimoniale du bien immobilier détenu par cette société.

Gêne : En l’état, le moteur peut supprimer : des questions utiles sur le bien ; des documents nécessaires à sa valorisation ; des informations sur les charges ; ou des éléments liés à son financement. Cela peut conduire à sous-analyser un actif important du patrimoine alors même que sa société propriétaire sera, de son côté, correctement analysée dans une autre rubrique.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Patrimoine professionnel », la rubrique « Activité d’exploitation » prévoit actuellement notamment la demande suivante : « Bilan comptable détaillé et compte de résultat détaillé » Pour l’analyse patrimoniale et professionnelle, disposer d’un seul exercice est souvent insuffisant. Lorsque la société dispose d’un historique suffisant, il est préférable de pouvoir analyser les trois derniers exercices comptables afin d’apprécier l’évolution de l’activité, des résultats et de la structure financière.

Attendu : Remplacer la demande actuelle par une formulation du type : Trois derniers bilans comptables et comptes de résultat disponibles ou, de manière encore plus explicite : Bilans comptables et comptes de résultat des trois derniers exercices clos La règle doit tenir compte de l’ancienneté de la société : société disposant d’au moins 3 exercices clos → demander les 3 derniers exercices ; société disposant de 2 exercices clos → demander les 2 exercices disponibles ; société disposant d’un seul exercice clos → demander l’exercice disponible ; société récente sans exercice clos → ne pas demander artificiellement trois bilans inexistants. Une mention complémentaire pourrait préciser : Si la société a moins de trois exercices clos, transmettre l’ensemble des comptes disponibles.

Intention : Permettre à l’ingénieur patrimonial de disposer d’un historique suffisamment représentatif pour apprécier : l’évolution du chiffre d’affaires ; la rentabilité ; la structure du bilan ; l’endettement ; la trésorerie ; et, plus largement, les tendances de l’activité.

Gêne : Un seul exercice peut donner une photographie ponctuelle sans permettre d’identifier une tendance ou une anomalie exceptionnelle. La collecte des trois derniers exercices, lorsque disponibles, permet une analyse plus fiable tout en évitant de demander au client des documents qui n’existent pas lorsque la société est récente.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, il est indiqué en haut de page : « Le moteur conditionnel a présélectionné les pièces pertinentes selon le DCI · ajustez à la main avant l’envoi. » Or, dans le cas présenté, la collecte affiche : 350 éléments au total ; 321 sélectionnés ; seulement 29 non inclus. Autrement dit, la quasi-totalité de la base est présélectionnée, alors même que le principe annoncé est celui d’un moteur conditionnel fondé sur les réponses du DCI et du questionnaire de qualification. Cela donne fortement l’impression que le moteur ne réalise pas réellement de filtrage métier, ou qu’il applique des règles beaucoup trop larges.

Attendu : La présélection doit être réellement conditionnelle et proportionnée à la situation du dossier. Le moteur doit : partir des informations déjà renseignées dans le DCI ; tenir compte des réponses apportées par l’ingénieur patrimonial dans le questionnaire de qualification ; exclure automatiquement les questions déjà renseignées ; exclure les documents qui ne sont pas pertinents au regard de la situation déclarée ; ne sélectionner que les questions et pièces réellement utiles pour compléter ou vérifier le dossier. L’ingénieur doit ensuite pouvoir ajuster manuellement cette proposition, mais cette intervention doit être une correction à la marge, pas un nettoyage massif de centaines d’éléments. Exemple de logique attendue Si le foyer : n’a pas de situation internationale ; ne détient pas de société ; n’a pas de dispositif fiscal immobilier ; n’a pas de situation de handicap ; n’a pas d’enfant adopté ; etc., alors les questions et pièces spécifiques à ces situations ne doivent pas être présélectionnées. À l’inverse, si un élément du dossier déclenche un besoin particulier, les questions et documents correspondants doivent apparaître automatiquement. Contrôle à effectuer Il faudrait vérifier : que les règles conditionnelles sont bien appliquées sur toutes les sections ; que les réponses du DCI sont réellement lues par le moteur ; que les réponses du questionnaire de qualification modifient bien la présélection ; que les éléments exclus par une réponse Non sont bien retirés ; que les éléments déjà renseignés ne restent pas inutilement demandés ; que les compteurs Toutes / Sélectionnées / Non incluses reflètent bien le résultat du moteur.

Intention : Faire de la présélection automatique une vraie aide à la préparation de la collecte, plutôt qu’une sélection quasi exhaustive nécessitant un tri manuel important.

Gêne : Si presque toute la bibliothèque est sélectionnée par défaut : le client risque de recevoir une collecte disproportionnée ; l’ingénieur doit effectuer un travail de nettoyage très lourd ; le risque d’oublier de retirer une question ou une pièce non pertinente augmente ; le moteur conditionnel perd son intérêt opérationnel ; le message affiché en haut de page devient incohérent avec le comportement réel de l’outil.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Identité et situation familiale », la liste des documents à demander au client comporte actuellement : Justificatif de domicile récent Cette pièce est à supprimer de la collecte. Dans le fonctionnement retenu pour le parcours, l’avis d’impôt déjà demandé au client doit servir de pièce de référence pour justifier l’adresse du foyer. Il n’est donc pas nécessaire de demander en parallèle un justificatif de domicile supplémentaire.

Attendu : La pièce demandée "justificatif de domicile" est à supprimer de la liste. L'avis d'impôt fera le même office. Donc pas besoin du justificatif. Titre du ticket Supprimer le « justificatif de domicile récent » des pièces demandées dans la collecte documentaire Problème / demande À l’étape 3 – Collecte et analyse documentaire, dans la section « Identité et situation familiale », la liste des documents à demander au client comporte actuellement : Justificatif de domicile récent Cette pièce est à supprimer de la collecte. Dans le fonctionnement retenu pour le parcours, l’avis d’impôt déjà demandé au client doit servir de pièce de référence pour justifier l’adresse du foyer. Il n’est donc pas nécessaire de demander en parallèle un justificatif de domicile supplémentaire. Ce que cela devrait faire Supprimer « Justificatif de domicile récent » : de la liste des pièces proposées dans « Documents à demander au client » ; de la sélection automatique par défaut ; des compteurs de pièces disponibles / sélectionnées ; et, plus généralement, de tout autre endroit de la collecte où cette pièce serait ajoutée automatiquement pour ce même besoin. L’avis d’impôt, déjà collecté dans la partie fiscale, reste la pièce utilisée dans le parcours pour disposer de l’adresse déclarée du foyer. Attention à la logique de déduplication Il ne s’agit pas simplement de décocher la pièce sur cet écran : elle ne doit plus être automatiquement réintroduite ultérieurement par une autre règle de composition de la collecte.

Intention : Alléger la liste documentaire demandée au client et éviter de solliciter deux pièces pour une information que le parcours prévoit déjà de récupérer à travers l’avis d’impôt.

Gêne : Demander à la fois : un avis d’impôt ; et un justificatif de domicile récent ; alourdit inutilement la collecte et donne au client l’impression de devoir fournir plusieurs justificatifs pour une même information.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, l’ingénieur patrimonial prépare la collecte en travaillant section par section. Pour chaque thème : la colonne de gauche contient le questionnaire de qualification et les réponses Oui / Non à renseigner par l’ingénieur ; la colonne de droite présente les questions et documents qui seront demandés au client en fonction de ces réponses. Lorsque l’ingénieur quitte cette préparation en cours de route puis revient ultérieurement, il n’existe aujourd’hui aucun indicateur clair permettant de savoir quelles sections ont déjà été entièrement vérifiées et lesquelles restent à traiter. La seule méthode consiste à parcourir la colonne de gauche et à rechercher les questions encore sans réponse, ce qui devient peu pratique compte tenu du nombre de sections et d’éléments. Par ailleurs, lorsqu’une section est repliée dans la colonne de droite, la section correspondante de la colonne de gauche reste dépliée. Cela peut créer un grand espace vide à droite tout en conservant de nombreuses questions visibles à gauche, sans véritable cohérence entre les deux parties de l’écran.

Attendu : Deux évolutions complémentaires sont proposées. 1. Synchroniser le repli / dépli des deux colonnes Chaque section fonctionnelle doit être considérée comme un seul bloc, réparti entre les deux colonnes. Lorsque l’ingénieur : replie une section dans la colonne de droite la partie correspondante du questionnaire dans la colonne de gauche doit également se replier automatiquement. Inversement, lorsqu’il déplie la section : les questions de gauche réapparaissent ; les questions et documents de droite réapparaissent simultanément. Exemple : Fiscalité repliée à droite → Fiscalité également repliée à gauche. L’objectif est d’éviter qu’une moitié de la section reste ouverte alors que l’autre est masquée. 2. Ajouter un statut « Section prête pour la collecte » Chaque grande section devrait disposer d’une action permettant à l’ingénieur d’indiquer qu’il a terminé sa vérification. Par exemple : Marquer la section comme prête Lorsque l’ingénieur clique sur cette action : la configuration actuelle de la section est enregistrée ; la section passe dans un état visuel « Prête pour la collecte » ; elle se replie automatiquement dans les deux colonnes ; l’ingénieur peut immédiatement identifier que cette partie a déjà été contrôlée. L’état replié pourrait par exemple afficher : Fiscalité — Prête pour la collecte ✓ 14 pièces sélectionnées sur 17 ou un indicateur équivalent suffisamment visible. Consultation et modification ultérieure Une section marquée comme prête ne doit pas être verrouillée définitivement. L’ingénieur doit pouvoir la rouvrir pour : consulter les réponses renseignées ; vérifier les questions et pièces retenues ; modifier si nécessaire la configuration de la collecte. Lorsqu’une section déjà marquée « Prête pour la collecte » est modifiée, il faudrait distinguer clairement deux actions possibles : Consulter : ouverture sans remettre en cause la validation ; Modifier la configuration : la section repasse dans un état « À vérifier » ou équivalent jusqu’à une nouvelle validation. Ainsi, une modification réelle de la configuration doit nécessiter de cliquer à nouveau sur : Marquer comme prête avant de considérer la section comme finalisée. Reprise d’une collecte en cours Lorsqu’un ingénieur quitte puis revient sur la préparation de la collecte, l’interface doit conserver l’état des sections. Il doit alors pouvoir identifier immédiatement : les sections prêtes ; les sections encore à vérifier ; éventuellement les sections comportant encore des réponses manquantes. Cela permettrait de reprendre la préparation exactement à l’endroit où elle avait été interrompue. Vue d’ensemble Idéalement, le nombre de sections finalisées pourrait également alimenter un indicateur global, par exemple : 7 sections prêtes sur 11 Cela compléterait utilement le compteur actuel fondé principalement sur le nombre de questions ou de pièces sélectionnées.

Intention : Transformer la préparation de la collecte en un véritable workflow de validation section par section, plutôt qu’en une longue page dans laquelle l’ingénieur doit se souvenir mentalement de ce qu’il a déjà contrôlé.

Gêne : En l’état : il est difficile de reprendre une collecte interrompue ; aucune distinction claire n’existe entre une section déjà contrôlée et une section restant à traiter ; le repli de la colonne de droite n’est pas synchronisé avec la colonne de gauche ; certaines zones peuvent rester inutilement ouvertes et créer beaucoup d’espace vide ; une collecte comportant de nombreux thèmes devient difficile à parcourir et à contrôler.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Fiscalité », l’ingénieur patrimonial peut répondre à la question : « Le foyer a-t-il une situation internationale ? » Résidence fiscale, revenus ou biens hors de France. Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne semble produire aucune modification dans les questions ou les documents demandés au client. La question est donc renseignable mais n’est pas réellement exploitée pour construire la collecte.

Attendu : Cette question doit devenir une véritable condition de composition de la collecte. Si l’ingénieur répond « Oui », des questions complémentaires doivent permettre de qualifier la situation internationale du foyer. Il conviendrait notamment de recueillir, selon le cas : quel membre du foyer est concerné ; quel(s) pays sont concernés ; la nature de la situation : résidence fiscale à l’étranger ; revenus de source étrangère ; biens ou patrimoine détenus hors de France ; autre situation internationale à préciser ; les informations complémentaires nécessaires selon la situation déclarée. Les documents demandés doivent également s’adapter. Par exemple, lorsque la situation le justifie : avis d’imposition étranger ou justificatif fiscal étranger ; documents relatifs aux revenus étrangers ; justificatifs relatifs aux biens détenus à l’étranger ; autres documents fiscaux pertinents selon la situation identifiée. Si l’ingénieur répond « Non » : les questions spécifiquement destinées à qualifier une situation internationale doivent disparaître ; les documents exclusivement déclenchés par cette situation ne doivent pas être demandés. Attention aux autres déclencheurs Cette règle ne doit pas supprimer un document ou une question qui resterait nécessaire pour un autre motif renseigné ailleurs dans le questionnaire. Par exemple, la section comporte également une question distincte : « Le foyer détient-il des actifs financiers à l’étranger ? » Si cette autre question déclenche elle-même certaines obligations de collecte, les questions ou pièces correspondantes doivent naturellement rester présentes même si « Le foyer a-t-il une situation internationale ? » a été renseigné Non. Il faut donc gérer les dépendances par motif de déclenchement, et non simplement masquer globalement tout ce qui contient la notion d’étranger. Si aucune réponse n’est apportée Si l’ingénieur patrimonial ne renseigne ni Oui ni Non : la situation internationale doit rester à confirmer auprès du client ; les questions permettant de la qualifier doivent rester disponibles dans la collecte selon la logique générale de l’étape 3. Comportement attendu L’ingénieur sélectionne Oui, Non ou laisse la question sans réponse. La section Fiscalité se recalcule immédiatement. Si Oui, les questions de qualification et les éventuelles pièces correspondantes apparaissent. Si Non, elles disparaissent lorsqu’elles ne sont justifiées par aucun autre élément du dossier. Si la réponse est supprimée, les éléments à confirmer auprès du client réapparaissent. Les compteurs de questions et de pièces sélectionnées sont actualisés.

Intention : Faire en sorte que la question sur la situation internationale serve réellement à adapter la collecte et permette de comprendre précisément la nature et le pays de rattachement des éléments internationaux du foyer.

Gêne : En l’état, l’ingénieur peut signaler qu’un foyer présente une situation internationale sans qu’aucune information complémentaire ne soit recherchée. À l’inverse, s’il répond Non, les éléments internationaux potentiellement inutiles ne sont pas automatiquement retirés. La réponse apportée n’a donc actuellement aucune valeur opérationnelle dans la préparation de la collecte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Fiscalité », l’ingénieur patrimonial peut répondre à la question : « Les réductions ou crédits d’impôt vont-ils évoluer ? » Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne semble produire aucun effet sur les questions ni sur les documents demandés au client. La réponse est donc enregistrable mais n’est pas exploitée dans la construction dynamique de la collecte.

Attendu : Cette question doit devenir une véritable condition de composition de la collecte. Si l’ingénieur répond « Oui », il faut demander au client les informations permettant de comprendre cette évolution, par exemple : quelle réduction ou quel crédit d’impôt est concerné ? quelle est la nature de l’évolution prévue ? augmentation, diminution, disparition, nouveau dispositif… à partir de quelle année cette évolution est-elle attendue ? quelle en est la cause ? fin d’un dispositif, changement de dépense, emploi à domicile, garde d’enfant, dons, investissement fiscal, etc. quel serait le montant approximatif concerné, s’il est connu. Si un justificatif spécifique est pertinent et disponible, il peut également être demandé. En revanche, il ne faut pas créer artificiellement une pièce obligatoire lorsqu’aucun document particulier n’est nécessaire à ce stade. Si l’ingénieur répond « Non » : aucune question complémentaire sur une évolution future des réductions ou crédits d’impôt ne doit être adressée au client ; aucune pièce spécifique à cette évolution ne doit être ajoutée. Les documents fiscaux généraux nécessaires à l’analyse du dossier, tels que les avis d’impôt ou déclarations, doivent naturellement rester demandés s’ils le sont pour d’autres motifs : la réponse « Non » à cette seule question ne doit pas les supprimer. Si l’ingénieur ne renseigne aucune réponse : la question doit rester à recueillir ou à confirmer auprès du client. Comportement attendu La mise à jour doit être dynamique : l’ingénieur répond Oui, Non ou laisse la question non renseignée ; la rubrique Fiscalité est recalculée immédiatement ; si Oui, les questions de qualification de l’évolution apparaissent ; si Non, elles disparaissent ; si la réponse est supprimée, la question redevient à recueillir auprès du client ; les éventuels compteurs de questions et pièces sont actualisés. Cohérence avec la logique générale de la collecte Cette correction doit respecter le principe déjà attendu sur l’ensemble de l’étape 3 : une information déjà qualifiée par l’ingénieur patrimonial ne doit pas être redemandée telle quelle au client ; seules les précisions encore nécessaires doivent être ajoutées à la collecte. Ainsi, si l’ingénieur répond Oui, il ne faut pas redemander au client « Vos réductions ou crédits d’impôt vont-ils évoluer ? », mais directement lui demander les précisions nécessaires sur cette évolution.

Intention : Permettre à l’ingénieur patrimonial d’anticiper les évolutions de fiscalité du foyer et de comprendre leur origine, plutôt que de disposer d’un simple Oui / Non sans conséquence opérationnelle.

Gêne : En l’état, une évolution potentiellement importante de la fiscalité du foyer peut être signalée sans qu’aucune information complémentaire ne soit recueillie. L’ingénieur ignore alors notamment : quel avantage fiscal est concerné ; pourquoi il évolue ; à quelle échéance ; et dans quel ordre de grandeur.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Fiscalité », l’ingénieur patrimonial peut actuellement répondre à la question : « Le foyer bénéficie-t-il d’un dispositif fiscal immobilier ? » Lorsque la réponse est Oui, la collecte s’adapte correctement en ajoutant notamment, dans les documents à demander au client : « Justificatifs de dispositifs fiscaux immobiliers » Cette logique est pertinente, mais le périmètre actuel est trop restrictif : tous les dispositifs ou avantages fiscaux dont bénéficie un foyer ne sont pas immobiliers. Il peut notamment exister des dispositifs d’investissement à finalité fiscale non immobiliers, par exemple le Girardin industriel, mais également différentes réductions ou crédits d’impôt liés à la situation et aux dépenses du foyer. Par ailleurs, la seule connaissance du montant d’une réduction ou d’un crédit d’impôt n’est pas suffisante pour l’analyse patrimoniale. L’ingénieur patrimonial doit pouvoir identifier la nature de l’avantage fiscal, car son traitement, ses conditions et les limites applicables peuvent différer selon son origine.

Attendu : La rubrique Fiscalité devrait distinguer plusieurs catégories plutôt que de se limiter aux dispositifs fiscaux immobiliers. 1. Conserver les dispositifs fiscaux immobiliers La question actuelle peut être conservée : Le foyer bénéficie-t-il d’un dispositif fiscal immobilier ? Si Oui, demander : le type de dispositif ; éventuellement le bien concerné ; les informations utiles déjà disponibles ; les justificatifs du dispositif fiscal immobilier. 2. Ajouter les autres dispositifs fiscaux Ajouter une question distincte, par exemple : Le foyer bénéficie-t-il d’un autre dispositif fiscal ou investissement ouvrant droit à un avantage fiscal ? Si Oui, demander au client de préciser notamment : la nature du dispositif ; éventuellement le montant investi ou l’avantage fiscal correspondant lorsqu’il est connu ; l’année ou les années concernées ; les justificatifs disponibles. Cette rubrique doit pouvoir couvrir notamment des dispositifs qui ne sont pas immobiliers, tels qu’un investissement Girardin industriel, sans les faire artificiellement entrer dans la catégorie « dispositif fiscal immobilier ». 3. Ajouter une qualification des réductions et crédits d’impôt Ajouter également une question du type : Le foyer bénéficie-t-il actuellement de réductions ou crédits d’impôt liés à certaines dépenses ou opérations ? Si Oui, permettre d’ajouter une ou plusieurs lignes avec au minimum : nature de la réduction ou du crédit d’impôt ; montant des dépenses concernées, si connu ; montant de l’avantage fiscal, si connu ; personne ou dépense concernée, lorsque cela est utile. La liste peut notamment prévoir des catégories telles que : dons ; emploi à domicile ; garde d’enfants ; autres réductions ou crédits d’impôt ; autre – à préciser. Pour certains postes, il faut pouvoir préciser davantage la nature de la dépense. Exemple pour emploi à domicile : Nature de l’emploi ou du service : garde d’enfants / ménage / assistance à domicile / jardinage / autre à préciser. L’objectif est d’éviter qu’un simple intitulé générique « emploi à domicile » masque la nature réelle de la dépense. Documents à demander au client La collecte documentaire doit également devenir conditionnelle. Selon les réponses renseignées, elle pourrait ajouter : justificatif du dispositif fiscal immobilier ; justificatif d’un dispositif fiscal non immobilier ; justificatif d’investissement ouvrant droit à avantage fiscal ; justificatifs des réductions ou crédits d’impôt déclarés, lorsque cela est nécessaire et pertinent. Il faut éviter une demande documentaire générique unique qui mélangerait toutes les situations. Comportement attendu La logique devrait être dynamique : l’ingénieur patrimonial renseigne les réponses dans la rubrique Fiscalité ; les questions complémentaires apparaissent uniquement pour les thèmes concernés ; les documents correspondants sont ajoutés à la collecte ; si l’ingénieur répond Non, les questions et pièces liées au thème ne sont pas demandées ; si aucune réponse n’est apportée, l’information reste à recueillir auprès du client.

Intention : Permettre à l’ingénieur patrimonial d’identifier non seulement l’existence d’un avantage fiscal, mais également sa nature, afin de disposer d’une vision correcte des dispositifs, réductions et crédits d’impôt dont bénéficie le foyer.

Gêne : En l’état : la qualification est centrée sur les seuls dispositifs fiscaux immobiliers ; un dispositif fiscal non immobilier peut ne pas être identifié correctement ; une réduction ou un crédit d’impôt peut apparaître dans les déclarations sans que l’ingénieur sache précisément ce qui le génère ; des situations différentes peuvent être regroupées sous un même montant alors qu’elles doivent être analysées séparément ; la collecte documentaire risque de ne pas demander les justificatifs adaptés.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Budget », l’ingénieur patrimonial peut répondre à la question : « Une rentrée d’argent est-elle prévue ? » Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne semble avoir aucun impact sur les sous-rubriques ni sur les éléments qui seront ensuite demandés au client. La rubrique « Projets de flux » reste inchangée et aucune question complémentaire n’est ajoutée lorsque la réponse est Oui. La question est donc aujourd’hui renseignable, mais elle n’est pas exploitée dans la construction dynamique de la collecte.

Attendu : Cette question doit fonctionner comme une véritable condition de composition de la collecte. Si l’ingénieur répond « Oui » : des questions complémentaires doivent apparaître pour qualifier la rentrée d’argent prévue. Il conviendrait au minimum de recueillir : la nature de la rentrée d’argent ; le montant estimé, s’il est connu ; l’échéance ou l’horizon envisagé ; éventuellement la personne du foyer concernée. Par exemple : Quelle rentrée d’argent le foyer anticipe-t-il ? Quel montant approximatif est attendu ? À quelle échéance cette rentrée d’argent est-elle prévue ? Selon la nature de la rentrée d’argent, des pièces justificatives pourraient éventuellement être demandées, mais uniquement lorsqu’elles sont réellement pertinentes. Si l’ingénieur répond « Non » : aucune question complémentaire sur ce thème ne doit être posée au client ; aucune pièce spécifique ne doit être ajoutée à la collecte. Si aucune réponse n’a encore été renseignée : la question doit rester à recueillir ou à confirmer auprès du client, conformément à la logique générale de la collecte. Comportement attendu La mise à jour doit être dynamique : l’ingénieur répond Oui ou Non ; la rubrique « Projets de flux » est recalculée ; les questions complémentaires apparaissent uniquement si nécessaires ; les éventuelles pièces associées sont ajoutées ou retirées ; les compteurs de questions et de pièces sont actualisés. Cohérence avec les autres questions de la section Budget Ce dysfonctionnement est exactement du même ordre que celui constaté sur : « Le foyer épargne-t-il tous les mois ? » « Une dépense importante est-elle prévue ? » Il faut donc vérifier que les trois questions conditionnelles de la section Budget alimentent réellement la composition de la collecte et ne restent pas de simples champs sans conséquence.

Intention : Faire en sorte que les futurs flux financiers importants soient réellement qualifiés lorsqu’ils existent, sans poser de questions inutiles lorsqu’ils n’existent pas.

Gêne : En l’état, une information potentiellement importante pour l’analyse patrimoniale peut être renseignée par l’ingénieur sans qu’aucune précision complémentaire ne soit recueillie. Si la réponse est Oui, l’ingénieur ne dispose ensuite d’aucune information sur : l’origine du flux ; son montant ; son échéance.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Budget », l’ingénieur patrimonial peut répondre à la question : « Une dépense importante est-elle prévue ? » Actuellement, que l’ingénieur patrimonial sélectionne Oui ou Non, cela ne semble produire aucun effet sur les éléments à recueillir auprès du client. La rubrique « Projets de flux » reste notamment inchangée et aucune question complémentaire n’est ajoutée lorsque la réponse est Oui. La question est donc actuellement renseignable, mais sans effet réel sur la construction de la collecte.

Attendu : Cette question doit devenir une véritable condition de composition de la collecte. Si l’ingénieur répond « Oui » : des informations complémentaires doivent être demandées au client afin de qualifier cette dépense importante. Il conviendrait au minimum de recueillir : la nature / l’objet de la dépense prévue ; le montant estimé, s’il est connu ; l’échéance ou l’horizon envisagé ; éventuellement la personne du foyer concernée si cela est pertinent. Par exemple : Quelle dépense importante le foyer prévoit-il ? Quel montant approximatif est envisagé ? À quelle échéance cette dépense est-elle prévue ? Les éventuelles pièces justificatives ne doivent être ajoutées que lorsqu’un document est réellement pertinent à ce stade. Il ne faut pas créer artificiellement une demande documentaire si la nature de la dépense ne la justifie pas. Si l’ingénieur répond « Non » : aucune question complémentaire sur ce sujet ne doit être demandée au client ; aucune pièce spécifique à ce thème ne doit être sélectionnée. Si aucune réponse n’a encore été donnée : la question doit rester à recueillir ou à confirmer auprès du client, conformément à la logique générale de la collecte. Comportement attendu La mise à jour doit être dynamique : l’ingénieur sélectionne Oui ou Non ; la rubrique « Projets de flux » est recalculée immédiatement ; les questions complémentaires apparaissent uniquement si elles sont nécessaires ; les éventuelles pièces liées au thème sont ajoutées ou retirées selon la règle applicable ; les compteurs de questions et de pièces sont actualisés.

Intention : Faire en sorte que la question « Une dépense importante est-elle prévue ? » serve réellement à qualifier les futurs besoins de liquidité du foyer et adapte la collecte en conséquence.

Gêne : En l’état, l’ingénieur patrimonial peut répondre à la question sans que cette information soit exploitée. Si la réponse est Oui, aucune donnée complémentaire n’est recueillie pour comprendre : de quelle dépense il s’agit ; son montant ; son horizon. Une information potentiellement importante pour l’analyse de la liquidité et des projets du foyer reste donc inexploitable.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, dans la section « Budget » du questionnaire de qualification, l’ingénieur patrimonial peut répondre à la question : « Le foyer épargne-t-il tous les mois ? » Or, que la réponse soit Oui ou Non, cela ne semble produire aucune modification dans les sous-rubriques et questions qui seront ensuite adressées au client. La rubrique « Épargne » reste notamment composée des mêmes questions, parmi lesquelles : le foyer effectue-t-il des versements réguliers ou automatiques sur des produits d’épargne ou d’investissement ? pour chaque versement, quelle personne du foyer le réalise ? sur quel support chaque versement est-il effectué ? quel montant est versé à chaque fois ? à quelle périodicité ces versements interviennent-ils ? ces versements sont-ils automatiques ou décidés au cas par cas ? La réponse apportée par l’ingénieur à la question « Le foyer épargne-t-il tous les mois ? » paraît donc actuellement sans effet sur la construction de la collecte.

Attendu : Cette question doit devenir une véritable question conditionnelle permettant de déterminer les informations qu’il reste pertinent de demander au client. Si l’ingénieur répond « Oui » : les questions permettant de caractériser cette épargne doivent rester proposées au client, notamment celles portant sur : la personne qui épargne ; le support concerné ; le montant ; la périodicité ; le caractère automatique ou ponctuel des versements. Si l’ingénieur répond « Non » : les questions spécifiquement destinées à détailler une épargne régulière / périodique doivent être retirées automatiquement de la collecte. Il ne paraît notamment pas pertinent de demander ensuite au client le montant, la périodicité ou les supports de versements réguliers si l’ingénieur vient précisément d’indiquer que le foyer n’épargne pas régulièrement. Si aucune réponse n’est renseignée : la question doit rester à recueillir auprès du client, conformément à la logique générale de la collecte. Attention sur la qualification La formulation actuelle porte sur : « épargne-t-il tous les mois ? » alors que les questions de droite semblent plus largement concerner des versements réguliers ou automatiques, qui ne sont pas nécessairement mensuels. Il faudrait donc vérifier la cohérence entre la question de qualification et les sous-questions qu’elle conditionne. Une formulation plus cohérente pourrait par exemple être : « Le foyer effectue-t-il des versements réguliers sur des produits d’épargne ou d’investissement ? » Cela permettrait ensuite de demander séparément la périodicité réelle. Comportement attendu Lorsqu’une réponse est sélectionnée par l’ingénieur patrimonial : la collecte se recalcule immédiatement ; les questions devenues inutiles disparaissent ; les questions restant nécessaires demeurent sélectionnées ; les compteurs de questions / éléments sont actualisés ; si la réponse est supprimée, les questions correspondantes redeviennent proposées.

Intention : Faire en sorte que chaque question du questionnaire de qualification ait une utilité réelle dans la construction dynamique de la collecte et éviter d’interroger le client sur des situations que l’ingénieur vient déjà d’exclure.

Gêne : En l’état, l’ingénieur peut renseigner une information sans que cela réduise ou adapte la collecte. Le client reçoit alors des questions qui peuvent être contradictoires avec une information déjà qualifiée, ce qui alourdit inutilement le questionnaire et donne l’impression que les réponses de l’ingénieur ne sont pas prises en compte.

https://ingenieur.astraeos.fr/espace-ingenieur/collectes/43c9a593-c457-4092-8598-249a4807fc10/modifier

Problème : À l’étape 3 – Collecte et analyse documentaire, le questionnaire de qualification situé à gauche permet à l’ingénieur patrimonial de compléter ou confirmer différentes informations relatives au foyer. Ces réponses servent à déterminer les questions à poser au client et les pièces à lui demander dans la collecte documentaire. Actuellement, cette synchronisation ne fonctionne pas correctement. Lorsqu’une réponse est renseignée par l’ingénieur patrimonial, la question correspondante peut rester sélectionnée dans le bloc « Questions et informations à recueillir auprès du client », et les pièces associées au même thème peuvent également rester demandées. Le problème a notamment été constaté dans « Identité et situation familiale », par exemple pour : la situation de handicap d’un membre du foyer ; l’adoption d’un enfant ; le décès d’un enfant ; le rattachement ou l’aide apportée à un enfant majeur. Mais le ticket doit être traité avec un périmètre beaucoup plus large : cette logique doit fonctionner dans toutes les sections du questionnaire de qualification qui composent la collecte, et pas uniquement dans « Identité et situation familiale ».

Attendu : Le principe général doit être le suivant : Tout élément déjà renseigné par l’ingénieur patrimonial ne doit plus être demandé au client dans la collecte. Lorsqu’une question du questionnaire de qualification n’a encore reçu aucune réponse de l’ingénieur patrimonial : elle doit rester proposée dans les informations à recueillir auprès du client ; les pièces documentaires prévues pour ce thème doivent rester proposées selon les règles de la collecte. Dès que l’ingénieur patrimonial renseigne une réponse, quelle que soit la réponse apportée : la question correspondante doit automatiquement disparaître des informations à recueillir auprès du client ; les pièces demandées au client sur ce même thème doivent également être retirées de la collecte ; les compteurs de questions et de pièces sélectionnées doivent être recalculés automatiquement. L’ingénieur ne doit pas avoir à décocher manuellement ce qui vient d’être renseigné. Exemple Si l’ingénieur patrimonial répond : Une personne du foyer est-elle en situation de handicap ? → Non alors : cette question ne doit plus être posée au client ; les éventuelles pièces prévues spécifiquement sur le thème du handicap ne doivent plus être demandées. Même logique si l’ingénieur répond à une question concernant : un enfant adopté ; un enfant décédé ; une situation professionnelle ; les revenus ; le budget ; la fiscalité ; la détention d’un actif ; un crédit ; une assurance ; ou tout autre thème utilisé pour construire la collecte. Périmètre attendu La correction doit être implémentée comme une règle transversale du moteur de composition de la collecte. Elle doit fonctionner sur l’ensemble des sections du questionnaire de qualification, notamment toutes celles qui alimentent : les questions complémentaires à poser au client ; les informations à confirmer ; les documents à demander ; les conditions d’apparition ou de disparition de certaines pièces. Il ne s’agit donc pas de corriger individuellement les quelques questions visibles sur la capture, mais de vérifier que chaque réponse renseignée dans le questionnaire de qualification est correctement propagée vers la composition de la collecte. Comportement dynamique attendu La mise à jour doit être immédiate. L’ingénieur patrimonial renseigne ou modifie une réponse dans le questionnaire de qualification. La composition de la collecte est recalculée. La question désormais renseignée disparaît des éléments à recueillir auprès du client. Les pièces associées à ce thème disparaissent également. Les compteurs et la sélection globale sont mis à jour. Si la réponse est ensuite supprimée et que le champ redevient non renseigné, la question et les éléments associés doivent redevenir proposés dans la collecte.

Intention : Faire du questionnaire de qualification de l’ingénieur patrimonial la source de référence permettant d’éviter toute demande redondante au client. La collecte documentaire doit uniquement contenir ce qui reste effectivement à obtenir ou à confirmer.

Gêne : Sans cette synchronisation globale : le client reçoit des questions auxquelles l’ingénieur a déjà répondu ; des pièces sont demandées alors que le sujet a déjà été qualifié ; la collecte est artificiellement allongée ; l’ingénieur doit effectuer un nettoyage manuel de centaines d’éléments potentiels ; le client peut avoir l’impression que les informations déjà communiquées n’ont pas été prises en compte ; le risque d’incohérence augmente entre les informations connues du cabinet et celles redemandées au client.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite

Problème : Depuis la fiche d’un prospect, le bouton « Faire passer en étape 2 » permet de faire basculer le dossier vers l’étape « Conformité en cours ». Le premier passage fonctionne, mais l’action reste ensuite disponible depuis la fiche prospect. Si l’ingénieur patrimonial clique une nouvelle fois sur « Faire passer en étape 2 », un nouveau dossier de conformité est créé au lieu de réutiliser le dossier déjà existant. Dans le cas présenté, le couple Tristan LANGLOIS et Sarah PABOIS apparaît ainsi deux fois dans le tableau général « Conformité en cours », avec deux lignes correspondant au même foyer. Cela signifie que le lien entre le prospect d’origine et son dossier de conformité n’est pas suffisamment verrouillé ou réutilisé lors d’une nouvelle tentative de passage en étape 2.

Attendu : Le passage d’un prospect en étape 2 doit être unique et idempotent. Dès qu’un dossier de conformité a été créé pour un prospect ou un foyer : le bouton « Faire passer en étape 2 » ne doit plus permettre de recréer un nouveau dossier ; idéalement, il doit disparaître ou être remplacé par une action permettant d’ouvrir le dossier de conformité existant ; le statut de la fiche prospect doit refléter clairement que le dossier est déjà passé en conformité. Par exemple : Dossier déjà en conformité Ouvrir le dossier de conformité Sécurisation côté données La correction ne doit pas reposer uniquement sur l’interface. Même si une requête de passage en étape 2 est déclenchée plusieurs fois, le système doit vérifier s’il existe déjà un dossier de conformité rattaché au prospect ou au foyer concerné. S’il existe : ne pas créer de nouveau dossier ; réutiliser le dossier existant ; conserver les liens avec les personnes, documents, questionnaires et données déjà rattachés. Le contrôle doit notamment fonctionner pour les dossiers constitués en couple, afin que le même foyer ne puisse pas être dupliqué sous deux identifiants de conformité distincts. Cas à contrôler Le comportement doit être sécurisé notamment dans les cas suivants : double clic ou clic répété sur « Faire passer en étape 2 » ; retour ultérieur sur la fiche prospect après le premier passage ; rechargement de la page puis nouvelle tentative ; appel multiple de la même action côté serveur ; foyer composé de plusieurs membres.

Intention : Garantir qu’un prospect ou un foyer ne dispose que d’un seul dossier actif correspondant à son parcours, et maintenir une continuité fiable entre la fiche prospect et la fiche conformité.

Gêne : La création de doublons à l’étape conformité peut entraîner : deux dossiers actifs pour les mêmes personnes ; des documents ou signatures répartis entre plusieurs dossiers ; des statuts divergents ; des erreurs de suivi ; des relances envoyées depuis le mauvais dossier ; une perte de traçabilité entre les différentes étapes du parcours patrimonial. Le risque est donc plus important qu’un simple doublon visuel : il peut affecter l’intégrité du dossier et la poursuite du parcours.

https://ingenieur.astraeos.fr/espace-ingenieur/prospects/tristan-langlois-f681d34b

Problème : Depuis la page Prospects, lorsqu’un ingénieur patrimonial crée un rendez-vous, la fenêtre « Nouveau rendez-vous » permet de sélectionner les formulaires et contenus qui seront envoyés avec la confirmation du rendez-vous. Actuellement, deux éléments sont directement proposés sous forme de sélection : DCI simplifié ; Questionnaire de qualification client. Le DCI complet est bien disponible, mais uniquement dans la liste secondaire « Ajouter un élément pour ce rendez-vous ». Cette présentation n’est pas cohérente avec l’usage attendu : le DCI complet peut être un document principal à envoyer en amont de l’entretien, au même titre que le DCI simplifié.

Attendu : Ajouter directement le DCI complet dans la liste principale « Formulaires et contenus envoyés avec la confirmation », au même niveau que : DCI simplifié ; Questionnaire de qualification client. L’ingénieur patrimonial doit pouvoir le sélectionner ou le désélectionner simplement depuis cette zone, sans devoir passer par la liste déroulante secondaire. Le fonctionnement attendu est donc par exemple : ☐ DCI simplifié ☐ DCI complet ☐ Questionnaire de qualification client La logique de sélection doit rester compatible avec les besoins du rendez-vous : l’ingénieur patrimonial doit pouvoir choisir les formulaires réellement utiles au dossier. Adapter automatiquement le contenu du mail La sélection du DCI complet doit également modifier automatiquement le texte du mail de confirmation, exactement comme c’est déjà le cas pour les autres formulaires. Si le DCI complet est sélectionné, le mail doit notamment indiquer clairement au prospect qu’un DCI complet lui est transmis / proposé à compléter dans le cadre de la préparation du rendez-vous. Si le formulaire est ensuite désélectionné, la mention correspondante doit disparaître automatiquement du message. Le texte du mail doit donc rester synchronisé avec les éléments réellement sélectionnés au moment de l’envoi.

Intention : Permettre à l’ingénieur patrimonial de choisir rapidement, dès la création du rendez-vous, le niveau de collecte adapté au dossier et éviter de traiter le DCI complet comme un contenu secondaire alors qu’il peut constituer le formulaire principal de préparation de l’entretien.

Gêne : Le DCI complet est actuellement disponible mais rangé dans une logique d’ajout complémentaire, ce qui le rend moins visible et moins naturel à sélectionner. Cela crée également une incohérence avec le DCI simplifié, alors que les deux documents peuvent remplir la même fonction générale de préparation du rendez-vous avec des niveaux de détail différents.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 22 sur 22 du DCI simplifié, sur la page « Validation et signature », l’encart « Contrôles de conformité internes » pose deux problèmes. D’abord, la police utilisée pour le titre et le texte de cet encart est particulièrement petite par rapport au reste de la page. L’information devient difficile à lire alors qu’elle intervient au moment de la validation finale du questionnaire. Ensuite, la formulation actuelle : « Les vérifications ANACOFI seront effectuées par votre ingénieur patrimonial avant l’envoi définitif pour signature : contrôles réservés au cabinet. » n’est pas très claire pour le prospect. La mention d’ANACOFI et l’expression « contrôles réservés au cabinet » introduisent un vocabulaire interne qui n’apporte pas réellement d’information utile au client et peuvent lui faire se demander ce qu’il reste encore à faire de son côté.

Attendu : Titre du ticket Améliorer la lisibilité et reformuler l’encart « Contrôles de conformité internes » à l’étape de validation Problème / demande À l’étape 22 sur 22 du DCI simplifié, sur la page « Validation et signature », l’encart « Contrôles de conformité internes » pose deux problèmes. D’abord, la police utilisée pour le titre et le texte de cet encart est particulièrement petite par rapport au reste de la page. L’information devient difficile à lire alors qu’elle intervient au moment de la validation finale du questionnaire. Ensuite, la formulation actuelle : « Les vérifications ANACOFI seront effectuées par votre ingénieur patrimonial avant l’envoi définitif pour signature : contrôles réservés au cabinet. » n’est pas très claire pour le prospect. La mention d’ANACOFI et l’expression « contrôles réservés au cabinet » introduisent un vocabulaire interne qui n’apporte pas réellement d’information utile au client et peuvent lui faire se demander ce qu’il reste encore à faire de son côté. Ce que cela devrait faire 1. Améliorer la lisibilité de l’encart Augmenter la taille de police du titre et du texte pour qu’ils soient cohérents avec les autres informations secondaires de la page et restent facilement lisibles. L’encart peut conserver une présentation discrète puisqu’il s’agit d’une information complémentaire, mais pas au point de devenir difficile à lire. 2. Simplifier la formulation Utiliser une phrase directement compréhensible par le prospect, sans terminologie interne inutile. Proposition : Contrôle de conformité Les vérifications de conformité nécessaires seront réalisées par votre ingénieur patrimonial avant l’envoi définitif de votre document de collecte d’informations pour signature. Une formulation encore plus simple pourrait être : Contrôle de conformité Votre ingénieur patrimonial vérifiera les informations nécessaires à la conformité du dossier avant l’envoi définitif du document pour signature. Cette deuxième version me paraît préférable : elle est plus courte, évite le jargon et explique immédiatement au prospect ce qui va se passer. Il n’est pas nécessaire d’indiquer « contrôles réservés au cabinet » : le fait que la vérification soit réalisée par l’ingénieur patrimonial suffit à faire comprendre qu’aucune action supplémentaire n’est demandée au prospect.

Intention : Rendre la dernière étape du DCI plus rassurante et compréhensible, en distinguant clairement ce qui relève de la validation du prospect et ce qui sera ensuite contrôlé en interne par l’ingénieur patrimonial.

Gêne : Au moment de la validation finale, le prospect doit pouvoir comprendre immédiatement la suite du processus. Une police très petite et une formulation trop interne peuvent laisser penser qu’une action supplémentaire ou un contrôle réglementaire complexe lui incombe.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 22 sur 22 du DCI complet, deux erreurs de mise en forme apparaissent dans les textes de validation. La première se trouve dans l’encart « Votre conseiller et vos intérêts ». La phrase affiche actuellement : « la véracité, de l’exactitude et de l’exhaustivitédes informations… » Il manque un espace entre « exhaustivité » et « des ». La seconde se trouve dans le texte associé à la case à cocher de certification finale. Le texte affiche actuellement : « Je certifie l’exactitude et l’exhaustivité des informationscommuniquées dans ce document. » Il manque un espace entre « informations » et « communiquées ».

Attendu : Corriger les deux textes pour afficher : « la véracité, de l’exactitude et de l’exhaustivité des informations… » et : « Je certifie l’exactitude et l’exhaustivité des informations communiquées dans ce document. »

Intention : Corriger les erreurs typographiques présentes sur la dernière page du DCI complet, en particulier dans des textes liés à la conformité et à la certification des informations.

Gêne : Ces erreurs apparaissent au moment de la validation finale du questionnaire. Même mineures, elles donnent une impression de manque de finition sur une étape importante du parcours et sur des mentions à portée réglementaire.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 21 sur 22 du DCI complet, le prospect arrive sur une page intitulée : Synthèse de votre patrimoine avec l’instruction : « Vérifiez que les éléments consolidés correspondent à votre situation, puis poursuivez vers la signature. » Or, immédiatement après, l’encart « Photographie de votre patrimoine » précise que le patrimoine consolidé et les ratios financiers seront présentés ultérieurement par l’ingénieur patrimonial, à partir des informations déclarées. Il est également indiqué : « Poursuivez vers la signature : rien ne reste à saisir sur cette page. » La page demande donc au prospect de vérifier des éléments consolidés qui ne lui sont pas affichés. En l’état, aucune synthèse exploitable des informations renseignées dans les étapes précédentes n’est présentée. Le prospect ne peut donc matériellement effectuer le contrôle qui lui est demandé.

Attendu : Deux solutions sont possibles, mais le fonctionnement actuel doit être supprimé. Option privilégiée : transformer cette étape en page d’information avant signature. La page pourrait simplement expliquer que les informations renseignées vont être consolidées et exploitées par l’ingénieur patrimonial lors de l’entretien et de l’analyse du dossier. Par exemple : Vos informations patrimoniales ont bien été recueillies. Les éléments que vous venez de renseigner seront consolidés et analysés par votre ingénieur patrimonial. Ils serviront notamment de support à votre prochain entretien et permettront de préparer l’analyse de votre situation. Vous pourrez compléter ou préciser certaines informations avec votre ingénieur si nécessaire. Vous pouvez maintenant poursuivre vers la validation de votre questionnaire. Le titre pourrait alors être adapté, par exemple : Vos informations ont bien été recueillies ou : Avant de finaliser votre questionnaire Cette solution conserve une étape de transition avant la finalisation sans laisser croire au prospect qu’une synthèse patrimoniale complète lui est déjà présentée. Alternative : supprimer entièrement l’étape 21 si elle n’a aucune fonction opérationnelle particulière et faire passer directement le prospect de la dernière étape de saisie à l’étape de validation / signature. À éviter Ne pas conserver des formulations telles que : « Vérifiez que les éléments consolidés correspondent à votre situation » tant qu’aucune synthèse réelle des informations déclarées n’est effectivement affichée sur la page. De même, le titre « Synthèse de votre patrimoine » est trompeur si aucune synthèse patrimoniale n’est présentée.

Intention : Faire correspondre le contenu affiché à ce que le prospect peut réellement consulter à ce stade et éviter une étape qui donne l’impression qu’un contrôle doit être effectué alors qu’aucune donnée consolidée n’est accessible.

Gêne : Le prospect peut légitimement se demander : où se trouve la synthèse qu’il doit vérifier ; si une partie de la page ne s’est pas chargée ; s’il peut poursuivre sans avoir effectué le contrôle demandé ; si les informations renseignées précédemment ont bien été prises en compte. Cela crée une ambiguïté inutile juste avant la finalisation du DCI.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 20 sur 22 du DCI complet, lorsqu’un prospect ajoute un objectif et sélectionne : Autre · préciser le champ « Quel est cet objectif ? » reste un simple choix figé sur « Autre · préciser ». Le prospect ne peut donc pas renseigner lui-même le nom réel de son objectif. Par ailleurs, l’intitulé affiché dans l’en-tête de l’encart, à côté de son numéro, reste également : Autre · préciser même si le prospect détaille ensuite son objectif dans les autres champs. Cela empêche d’identifier rapidement l’objectif créé lorsqu’il y en a plusieurs.

Attendu : Lorsque le prospect sélectionne « Autre · préciser », un champ de saisie libre doit apparaître afin qu’il puisse renseigner un titre court pour son objectif. Par exemple : Autre · préciser Titre de l’objectif : Création d’une société avec mes enfants ou : Financer les études de mes petits-enfants Le fonctionnement attendu serait donc : le prospect sélectionne « Autre · préciser » ; un champ libre apparaît pour saisir le nom de l’objectif ; le titre renseigné est enregistré avec l’objectif ; l’en-tête de l’encart reprend automatiquement ce titre à la place de « Autre · préciser ». Par exemple, l’encart replié devrait afficher : 2 · Création d’une société avec mes enfants et non : 2 · Autre · préciser Le champ « Précisez le contexte et les enjeux » peut rester distinct afin de permettre au prospect de développer ensuite son besoin plus en détail. Comportement après modification Si le prospect modifie ultérieurement le titre de son objectif, l’intitulé de l’encart doit également se mettre à jour automatiquement. S’il remplace « Autre · préciser » par un objectif standard de la liste, le champ libre spécifique doit disparaître et l’intitulé de l’encart doit reprendre le libellé standard sélectionné.

Intention : Permettre au prospect de personnaliser réellement un objectif non prévu dans la liste et rendre immédiatement lisibles les différents objectifs créés.

Gêne : Lorsque plusieurs objectifs personnalisés sont ajoutés, des encarts intitulés uniquement « Autre · préciser » ne permettent pas de les distinguer sans relire leur contenu détaillé. Cela réduit fortement l’intérêt du classement et du réordonnancement proposés sur cette page.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 18 sur 22 du DCI complet – Emprunts et dettes, le formulaire demande actuellement un niveau de détail trop important pour une saisie réalisée directement par le prospect. Pour chaque emprunt, sont notamment demandés : la date de début ; le taux ; la durée totale ; la durée restante ; la mensualité ; le type d’assurance emprunteur ; la quotité ; la cotisation mensuelle d’assurance. Plusieurs de ces informations sont très précises et le prospect ne les connaît généralement pas de mémoire. Pour les renseigner correctement, il devrait rechercher son offre de prêt, son tableau d’amortissement ou ses documents d’assurance. Cela revient à lui demander d’effectuer en amont une partie du travail documentaire qui sera de toute façon réalisé ensuite par l’ingénieur patrimonial lors de la collecte et de l’analyse des pièces. Par ailleurs, le simple intitulé « Quotité » n’est pas suffisamment explicite : il ne permet pas de comprendre immédiatement qu’il s’agit de la quotité d’assurance emprunteur, éventuellement répartie entre plusieurs assurés.

Attendu : À ce stade du DCI complet, la fiche emprunt devrait être volontairement simplifiée et se concentrer sur les informations patrimoniales essentielles que le prospect est raisonnablement susceptible de connaître. Pour un prêt en cours, conserver principalement : capital initial emprunté ; capital restant dû ; durée restante en mois ; mensualité actuelle, assurance comprise, si elle est connue ; délégation d’assurance emprunteur : Oui / Non / Je ne sais pas. Le formulaire peut également rappeler clairement que seuls les emprunts encore en cours doivent être déclarés. La mensualité pourrait être présentée comme facultative, par exemple : Mensualité actuelle, assurance comprise – facultatif Informations à supprimer du DCI ou à reporter à l’analyse documentaire Les informations suivantes n’ont pas besoin d’être demandées directement au prospect dans le DCI complet : date de début du prêt ; taux du crédit ; durée totale initiale ; quotité(s) d’assurance ; montant spécifique de la cotisation mensuelle d’assurance. Ces éléments pourront être récupérés et fiabilisés ultérieurement à partir : de l’offre de prêt ; du tableau d’amortissement ; du contrat ou certificat d’assurance emprunteur ; des autres justificatifs collectés dans le dossier. L’objectif n’est pas de supprimer ces données du dossier patrimonial final, mais de déplacer leur collecte au bon moment, lors de l’analyse documentaire. Cas de l’assurance emprunteur À ce stade, il paraît suffisant de demander : Une délégation d’assurance emprunteur a-t-elle été mise en place ? Oui / Non / Je ne sais pas Il n’est pas nécessaire de demander au prospect de reconstituer les quotités d’assurance ou le montant exact de la prime mensuelle.

Intention : Alléger le DCI complet et concentrer les questions sur les informations réellement utiles à une première photographie patrimoniale, sans demander au prospect une recherche documentaire détaillée qui sera ensuite réalisée par l’ingénieur patrimonial.

Gêne : Le niveau de détail actuel : rallonge inutilement le questionnaire ; peut entraîner des abandons ou des réponses approximatives ; oblige le prospect à chercher des documents en cours de saisie ; crée un risque d’erreur sur des données qui pourront ensuite être obtenues de manière plus fiable à partir des pièces justificatives.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 18 sur 22 du DCI complet, dans la section « Emprunts et dettes », les champs : Durée totale Durée restante ne précisent pas l’unité attendue. Le prospect ne sait donc pas s’il doit renseigner une durée en années ou en mois. Dans l’exemple affiché, une valeur telle que 180 peut être comprise comme 180 mois, mais rien dans l’interface ne permet de le savoir avec certitude.

Attendu : Préciser directement dans l’intitulé des champs que les durées sont attendues en mois. Par exemple : Durée totale (en mois) Durée restante (en mois) ou, de manière plus compacte : Durée totale – mois Durée restante – mois Cette précision doit être visible directement au niveau du libellé, sans nécessiter d’infobulle ou d’explication complémentaire.

Intention : Éviter toute ambiguïté de saisie et garantir que les durées d’emprunt soient renseignées dans une unité homogène.

Gêne : Une confusion entre années et mois peut générer des données complètement erronées dans le dossier, puis fausser les calculs ou l’analyse du financement.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : Dans le DCI complet, lorsqu’un prospect renseigne un bien immobilier d’usage ou locatif et indique qu’un prêt est associé à ce bien, un message précise qu’une fiche emprunt a été automatiquement créée dans la section « Emprunts et dettes » et qu’elle pourra être complétée ultérieurement. Or, lorsque le prospect arrive ensuite à l’étape 18 sur 22 – Emprunts et dettes, aucun emprunt précréé n’apparaît. La section est vide et propose uniquement le bouton : Ajouter un prêt ou une dette Il y a donc une incohérence entre le message affiché lors de la saisie du bien immobilier et le contenu réellement retrouvé à l’étape 18.

Attendu : Dès qu’un prospect indique qu’un prêt est associé à un bien immobilier, une fiche emprunt liée au bien concerné doit être effectivement créée et retrouvée automatiquement à l’étape 18. Cette fiche peut rester incomplète tant que les caractéristiques du crédit n’ont pas été renseignées, mais elle doit au minimum permettre d’identifier immédiatement le bien auquel elle se rattache. Par exemple : Emprunt associé à la résidence principale – [adresse ou désignation du bien] À compléter ou, pour un bien locatif : Emprunt associé au bien locatif – [désignation du bien] À compléter La fiche doit ensuite pouvoir être ouverte pour renseigner les caractéristiques du financement. Le lien entre le bien et son emprunt doit également être conservé dans les données du dossier afin d’éviter qu’un crédit soit créé indépendamment sans possibilité de savoir quel actif il finance. Comportement attendu La logique devrait être la suivante : Le prospect crée un bien immobilier. Il répond « Oui » à la question indiquant qu’un prêt est associé à ce bien. Une fiche emprunt est automatiquement créée. À l’étape 18, cette fiche apparaît déjà sous forme d’un encart identifiable. Le prospect ouvre l’encart et complète les informations du crédit. Si plusieurs biens financés ont été renseignés, une fiche distincte doit être créée pour chacun d’eux. Il faut également éviter les doublons : si une fiche a déjà été créée automatiquement pour un bien, le passage à l’étape 18 ne doit pas en recréer une seconde.

Intention : Assurer une continuité logique entre la déclaration des actifs immobiliers et celle des passifs, tout en évitant au prospect de recréer manuellement un emprunt qu’il a déjà déclaré comme associé à un bien.

Gêne : Le message affiché lors de la saisie immobilière laisse actuellement croire que l’emprunt a bien été créé, alors que rien n’est retrouvé ensuite. Le prospect peut donc : penser que l’information a été perdue ; créer manuellement un nouvel emprunt ; générer un doublon si la création automatique existe malgré tout en base ; perdre le lien entre le crédit et le bien financé.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 17 sur 22 du DCI complet, la section « Mutuelle santé » ne fonctionne pas comme la section « Couverture prévoyance » située juste au-dessus. Pour les contrats de prévoyance, il est possible : d’ajouter plusieurs contrats ; de renseigner les informations d’un contrat ; de valider la saisie ; puis d’obtenir un encart replié permettant de créer ensuite un autre contrat. En revanche, pour la mutuelle santé, le formulaire reste unique et fixe. Il n’existe pas de bouton permettant d’ajouter un contrat de mutuelle, ni de mécanisme pour valider une fiche et la transformer en encart replié. Cela ne permet pas de gérer correctement les situations où le foyer dispose de plusieurs complémentaires santé, par exemple : une mutuelle différente pour chaque membre du couple ; une mutuelle individuelle pour l’un des membres et une mutuelle familiale pour l’autre ; plusieurs contrats couvrant des personnes différentes du foyer.

Attendu : La section « Mutuelle santé » devrait reprendre la même logique d’utilisation que la section « Couverture prévoyance ». Il faudrait pouvoir : cliquer sur un bouton du type « Ajouter un contrat de mutuelle » ; renseigner les informations du contrat ; valider / enregistrer la fiche ; replier automatiquement le contrat sous forme d’un encart synthétique ; ajouter ensuite un autre contrat si nécessaire ; modifier ou supprimer chaque contrat indépendamment. Une fois enregistré, l’encart replié devrait reprendre les principales informations permettant d’identifier le contrat, par exemple : APICIL Prévoyance – Ensemble du foyer – 120 €/mois ou : Harmonie Mutuelle – Sarah PABOIS – 85 €/mois La mention « À renseigner » ne devrait apparaître que tant que le contrat n’a pas encore été effectivement complété.

Intention : Permettre de représenter fidèlement les différentes couvertures santé du foyer et harmoniser le fonctionnement des contrats de mutuelle avec celui des contrats de prévoyance.

Gêne : Le formulaire actuel suppose implicitement qu’il n’existe qu’un seul contrat de mutuelle pour tout le foyer. Cette hypothèse peut être fausse et conduit soit à une information incomplète, soit à une impossibilité de distinguer les couvertures de chaque membre du couple.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : Dans plusieurs étapes du DCI complet, lorsqu’un prospect crée puis renseigne un support financier, les informations saisies ne sont pas reprises dans l’encart une fois celui-ci replié. Le problème ne concerne donc pas uniquement les liquidités ou les supports d’investissement de l’étape 13. Il apparaît plus largement sur les différentes étapes du DCI complet consacrées aux actifs financiers, par exemple : liquidités et comptes réglementés ; PEA, PEA-PME, compte-titres et autres investissements financiers ; assurance-vie ; contrat de capitalisation ; actifs atypiques ; PER ; PERP ; PERCO ; contrats Madelin ; et plus généralement les différents supports financiers créés dans le parcours. Après saisie, l’encart replié continue à afficher un intitulé générique du type : Nouvelle liquidité – À renseigner Nouveau support d’investissement – À renseigner Nouveau contrat retraite – À renseigner alors que la fiche a effectivement été complétée et enregistrée. Lorsque plusieurs supports sont créés, il devient donc impossible de les identifier sans les rouvrir individuellement.

Attendu : Mettre en place une logique commune sur l’ensemble du DCI complet : dès qu’un support est renseigné et enregistré, son encart replié doit afficher automatiquement les informations principales permettant de l’identifier. L’intitulé doit être adapté à la nature du support. Exemples : Compte courant – Tristan LANGLOIS & Sarah PABOIS – 12 000 € Livret A – Sarah PABOIS – 18 500 € PEA – Tristan LANGLOIS – 85 000 € Assurance-vie – Sarah PABOIS – 150 000 € PER individuel – Tristan LANGLOIS – 72 000 € Contrat de capitalisation – Tristan LANGLOIS – 200 000 € Selon le produit concerné, l’encart peut reprendre au minimum : le type de support ou de contrat ; le titulaire / détenteur ou les détenteurs ; la valorisation actuelle. Et, lorsqu’elle apporte réellement une information utile : la compagnie ou l’établissement ; une référence permettant de distinguer deux contrats similaires ; toute autre caractéristique essentielle propre au support. La logique doit s’adapter automatiquement au produit sans afficher inutilement des champs qui ne permettent pas de mieux l’identifier. Gestion de l’état « À renseigner » La mention : À renseigner ne doit rester visible que lorsqu’un encart vient réellement d’être créé et qu’aucune donnée significative n’a encore été enregistrée. Après enregistrement, l’intitulé doit être recalculé immédiatement. La même mise à jour doit intervenir après toute modification ultérieure du support. Périmètre La correction doit être traitée comme une règle globale de comportement des encarts repliés du DCI complet, et non comme une correction isolée d’une seule étape. Elle doit notamment être vérifiée sur toutes les sections permettant de créer plusieurs éléments patrimoniaux ou financiers : liquidités ; comptes réglementés ; investissements financiers ; assurance-vie ; capitalisation ; actifs atypiques ; épargne retraite ; épargne salariale si elle est intégrée dans le parcours ; et toute autre rubrique utilisant la même mécanique d’ajout / modification / repli d’un support.

Intention : Permettre au prospect comme à l’ingénieur patrimonial d’avoir immédiatement une vision lisible des supports déjà renseignés sans devoir ouvrir chaque fiche.

Gêne : Lorsque plusieurs encarts portent tous des intitulés génériques comme « Nouveau support » ou « Nouveau contrat », il devient difficile : d’identifier le support recherché ; de savoir ce qui a réellement été enregistré ; d’éviter les doublons ; de modifier le bon élément ; de contrôler rapidement la cohérence du patrimoine renseigné.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : Dans le DCI complet, les placements financiers sont actuellement répartis sur plusieurs étapes successives : Étape 13 – Placements financiers : liquidités, PEA, PEA-PME, compte-titres, PEE, PEI et autres supports d’investissement ; Étape 14 – Assurance-vie et capitalisation ; Étape 15 – Actifs atypiques ; Étape 16 – Épargne retraite : PER, PERP, contrats Madelin, PERCO, etc. Cette répartition est techniquement compréhensible, mais elle n’est pas nécessairement intuitive pour le prospect qui remplit son patrimoine. Lorsqu’il arrive à l’étape 13 intitulée « Placements financiers », il peut légitimement penser qu’il doit y déclarer l’ensemble de ses placements financiers. Il peut alors : chercher où renseigner son assurance-vie ; hésiter à ajouter son PER dans cette rubrique ; penser qu’un support a été oublié dans la liste proposée ; déclarer un produit dans une mauvaise catégorie avant de découvrir plusieurs pages plus loin qu’une étape spécifique lui était consacrée. Le problème vient donc moins du contenu de chaque fiche que de la logique de classement et de l’ordre de présentation du parcours.

Attendu : Repenser l’enchaînement de ces étapes autour de grandes catégories immédiatement compréhensibles pour un particulier. Une organisation plus claire pourrait être la suivante. 1. Liquidités et épargne bancaire Regrouper dans une première étape les supports de trésorerie et d’épargne bancaire, par exemple : compte courant ; Livret A ; LDDS ; LEP ; livret jeune ; livret bancaire ; PEL ; CEL ; compte à terme ; autres produits bancaires assimilables. Cette étape répondrait simplement à la logique : « Quelles liquidités et quels comptes d’épargne détenez-vous ? » 2. Placements et investissements financiers Créer ensuite une étape plus large regroupant les principaux placements financiers hors épargne retraite et salariale, notamment : PEA ; PEA-PME ; compte-titres ordinaire ; assurance-vie ; contrat de capitalisation ; autres enveloppes ou supports financiers pertinents. Le prospect commencerait par sélectionner le type de support, puis le formulaire s’adapterait automatiquement aux caractéristiques du produit choisi. Par exemple : un PEA pourrait faire apparaître les informations liées à son ouverture et à sa valorisation ; une assurance-vie pourrait faire apparaître les informations propres au contrat, au souscripteur, à sa valorisation et aux éléments spécifiques nécessaires ; un compte-titres pourrait présenter une fiche plus simple. L’objectif est de ne pas obliger le prospect à comprendre à l’avance l’architecture interne du DCI pour savoir sur quelle page déclarer son placement. 3. Épargne retraite et épargne salariale Regrouper ensuite dans une même grande étape les supports ayant une logique retraite ou d’épargne constituée dans un cadre professionnel, notamment : PER ; PERP ; contrat Madelin ; PERCO ; PEE ; PEI ; autres dispositifs assimilables. Là encore, le formulaire doit s’adapter au support sélectionné plutôt que de demander les mêmes informations pour tous les produits. Ce regroupement paraît plus naturel pour le prospect, qui identifiera plus facilement ces dispositifs comme une famille distincte de son épargne financière courante. 4. Actifs atypiques Les actifs atypiques peuvent rester dans une étape distincte afin de conserver une séparation claire avec les produits bancaires et financiers traditionnels. Principe général attendu L’organisation du DCI devrait suivre une logique de lecture simple : Liquidités bancaires → Placements financiers → Épargne retraite et salariale → Actifs atypiques ou une organisation équivalente conservant ces grandes familles. Le nombre exact d’étapes peut être adapté, mais le prospect doit comprendre immédiatement où déclarer chaque type d’actif. À l’intérieur de chaque famille, privilégier un fonctionnement : Sélection du type de support → affichage dynamique uniquement des champs pertinents pour ce support. Cela permettrait également de réduire le nombre de pages et d’éviter la multiplication de formulaires très proches.

Intention : Rendre le parcours patrimonial plus intuitif et limiter les erreurs de classement ou les hésitations du prospect au moment de déclarer ses placements.

Gêne : Le titre générique « Placements financiers » apparaît actuellement avant plusieurs étapes qui concernent elles-mêmes des placements financiers. Le prospect peut donc penser avoir terminé cette partie alors que l’assurance-vie, la capitalisation ou l’épargne retraite lui sont demandées seulement ensuite. Cette organisation augmente le risque : de doublons ; d’omissions ; de classement dans une mauvaise rubrique ; d’incompréhension du parcours ; de ressaisie lorsque le prospect découvre tardivement la rubrique réellement adaptée à son produit.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, lorsqu’une liquidité ou un support d’investissement financier est créé puis enregistré, les sections repliées continuent d’afficher des intitulés génériques du type : Nouvelle liquidité À renseigner ou : Nouveau support d’investissement À renseigner Cela reste le cas même lorsque le support a déjà été complété. Lorsque plusieurs supports sont créés, il devient alors difficile de savoir à quoi correspond chaque encart sans les rouvrir un par un.

Attendu : Une fois un support renseigné et enregistré, l’intitulé de la section repliée doit reprendre automatiquement les principales caractéristiques permettant de l’identifier. Pour une liquidité ou un compte réglementé, on pourrait par exemple afficher : Compte courant – Tristan LANGLOIS & Sarah PABOIS – 12 000 € ou : Livret A – Sarah PABOIS – 18 500 € Pour un support d’investissement financier : PEA – Tristan LANGLOIS – 85 000 € ou : Compte-titres ordinaire – Tristan LANGLOIS & Sarah PABOIS – 120 000 € Selon les données disponibles, l’encart replié devrait reprendre au minimum : le type de support ; le ou les détenteurs ; la valorisation actuelle. L’établissement ou une autre caractéristique pertinente pourrait également être ajouté si cela améliore l’identification. La mention « À renseigner » ne doit être conservée que lorsqu’aucune donnée significative n’a encore été enregistrée dans la fiche. La mise à jour de l’intitulé doit également intervenir après toute modification ultérieure du support.

Intention : Permettre au prospect et à l’ingénieur patrimonial d’identifier immédiatement les supports déjà renseignés, notamment lorsqu’il y en a plusieurs dans une même rubrique.

Gêne : Avec plusieurs encarts affichant tous « Nouvelle liquidité » ou « Nouveau support d’investissement », il faut ouvrir chaque fiche pour retrouver le support recherché. Cela rend la lecture du patrimoine financier peu exploitable et augmente le risque de modifier ou supprimer le mauvais élément.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, dans la rubrique « Liquidités et comptes réglementés », la liste proposée dans le champ « Type de support » est actuellement trop restreinte. Elle permet notamment de sélectionner : Livret A ; LDDS ; LEP ; Livret jeune ; Livret bancaire ; Compte à terme ; Compte courant. En revanche, certains supports courants ne sont pas proposés, notamment le PEL et le CEL. Le prospect ne peut donc pas qualifier correctement ces placements lorsqu’il les détient.

Attendu : Compléter la liste des types de supports proposés afin d’intégrer au minimum : PEL – Plan d’Épargne Logement ; CEL – Compte Épargne Logement. Ces supports doivent apparaître comme des choix distincts et ne pas être regroupés sous une catégorie générique de type « livret bancaire ». Le formulaire pourrait également adapter les informations demandées selon le support sélectionné. Pour le PEL et le CEL notamment, la date d’ouverture doit pouvoir être renseignée, car les caractéristiques du produit peuvent dépendre de son ancienneté. Plus généralement, la liste des supports de cette rubrique doit permettre d’identifier correctement les principales catégories de liquidités et d’épargne réglementée détenues par le foyer.

Intention : Permettre une qualification suffisamment précise des supports financiers dès le DCI complet, notamment lorsque leurs caractéristiques dépendent du type de produit et de sa date d’ouverture.

Gêne : En l’absence de PEL ou de CEL dans la liste, le prospect est contraint soit de sélectionner une catégorie incorrecte, soit de ne pas déclarer précisément le support. Cette approximation peut ensuite limiter la qualité de la collecte patrimoniale et nécessiter une reprise manuelle par l’ingénieur patrimonial.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, lorsqu’un prospect ajoute une liquidité ou un compte réglementé et renseigne effectivement le support, l’encart récapitulatif affiché ensuite ne reprend pas les informations saisies. Dans le cas testé, un compte courant a été créé et renseigné. Pourtant, une fois la fiche refermée, l’encart affiche encore : Nouvelle liquidité À renseigner Cette présentation laisse penser que le support n’a pas été complété alors qu’il l’a bien été.

Attendu : Dès qu’un support a été renseigné puis enregistré, l’encart replié doit reprendre les informations principales permettant de l’identifier immédiatement. Par exemple, pour un compte courant : Compte courant Tristan LANGLOIS & Sarah PABOIS · 400 € Selon les informations disponibles, l’encart pourrait afficher de manière synthétique : le type de support ; le ou les détenteurs ; le montant actuel ; éventuellement l’établissement si celui-ci est renseigné. La mention « À renseigner » ne doit apparaître que lorsqu’une fiche a réellement été créée mais qu’aucune information utile n’y a encore été enregistrée. L’affichage doit également se mettre à jour automatiquement après toute modification du support.

Intention : Permettre au prospect et à l’ingénieur patrimonial d’identifier immédiatement les supports déjà créés, sans devoir rouvrir chaque encart pour savoir ce qu’il contient.

Gêne : L’affichage actuel donne l’impression qu’une saisie déjà réalisée n’a pas été enregistrée. Cela crée de la confusion, peut conduire à créer un doublon et empêche d’avoir une lecture synthétique des placements déjà renseignés.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : À l’étape 13 sur 22 du DCI complet, lors de l’ajout d’un placement financier ou d’une liquidité, le formulaire demande systématiquement certaines informations et limite trop fortement la désignation du détenteur. Deux points sont à revoir. 1. Les champs « N° de contrat » et « Date d’ouverture » sont demandés quel que soit le support Ces informations peuvent être pertinentes pour certains produits lorsque leur ancienneté ou leur identification contractuelle présente un intérêt, par exemple un PEA, un PEL, une assurance-vie ou certains autres contrats. En revanche, pour des supports courants tels qu’un compte courant, un Livret A ou d’autres comptes de liquidités, ces informations sont souvent peu utiles à ce stade et le prospect ne les connaît généralement pas sans rechercher ses documents bancaires. Leur présence systématique alourdit donc inutilement le DCI. 2. Le détenteur ne peut actuellement être qu’une seule personne Le champ « Détenteur » permet uniquement de sélectionner individuellement l’un des membres du couple. Cela ne permet pas de représenter correctement les situations dans lesquelles un support est détenu conjointement ou fait l’objet d’une répartition des droits entre plusieurs personnes. Le formulaire doit pouvoir représenter une détention plus complexe sans imposer artificiellement un titulaire unique.

Attendu : Adapter les champs au type de support Les informations demandées doivent évoluer selon le support sélectionné. Pour des supports tels qu’un compte courant, Livret A, LDDS ou autre compte de liquidités simple, conserver principalement les données réellement utiles au DCI, notamment : type de support ; établissement ; montant actuel ; détenteur(s). Le numéro de contrat ou de compte et la date d’ouverture devraient être facultatifs, voire masqués lorsqu’ils ne présentent pas d’intérêt particulier pour le support sélectionné. Pour les produits dont l’ancienneté ou les caractéristiques contractuelles peuvent être importantes, ces champs peuvent en revanche être conservés et affichés de manière adaptée. Permettre plusieurs détenteurs Remplacer la logique actuelle de titulaire unique par un système permettant de représenter les différents détenteurs et leurs droits. La fiche pourrait notamment permettre d’ajouter : premier membre du couple ; second membre du couple ; enfant(s), en reprenant si possible les identités déjà renseignées dans le DCI ; tiers ; éventuellement une personne morale lorsque la situation le justifie. Pour chaque détenteur, prévoir lorsque cela est pertinent : une quote-part de détention en % ; la nature des droits : pleine propriété, usufruit, nue-propriété, lorsque ce type de démembrement est juridiquement possible pour le support concerné. La somme des quotes-parts concernées doit être contrôlée lorsque la logique du support impose un total de 100 %. Pour les supports dont le fonctionnement repose plutôt sur une cotitularité que sur une ventilation économique en pourcentage, le formulaire devra utiliser une qualification adaptée plutôt que d’imposer artificiellement une répartition à 50/50.

Intention : Alléger le DCI complet en ne demandant que les informations utiles selon la nature du placement et permettre une représentation fidèle de la détention des avoirs financiers du foyer.

Gêne : Le formulaire actuel oblige le prospect à rechercher des informations parfois secondaires et ne permet pas de retranscrire correctement les supports détenus conjointement ou faisant l’objet de droits répartis entre plusieurs personnes. Cela peut conduire soit à l’abandon de la saisie, soit à l’enregistrement d’une détention patrimoniale inexacte.

/espace-ingenieur/conformité

Problème : la page présente actuellement l’état des différents documents de manière assez dispersée, avec notamment des sabliers, différentes mentions et des actions qui ne sont pas toujours regroupées ou conditionnées à l’état réel du document.

Attendu : créer un tableau synthétique avec une ligne par document et au minimum les colonnes suivantes : document ; état ; actions. supprimer les pictogrammes de type sablier qui n’apportent pas d’information supplémentaire. la colonne « état » doit utiliser une nomenclature claire et homogène, par exemple : en attente ; prêt à envoyer ; envoyé ; en signature ; signé par le client ; finalisé. les états exacts devront être adaptés au cycle réel de chacun des documents. la colonne « actions » doit permettre, selon le contexte : de visualiser le document ; de modifier ou éditer le document lorsque cela est possible ; de relancer le client lorsque le document lui a effectivement été envoyé ; et toute autre action pertinente selon son état. chaque action doit être représentée uniquement par un pictogramme, sans répéter un verbe à côté. une infobulle au survol précise la fonction du pictogramme. les actions doivent être strictement conditionnées à l’état du document. par exemple, aucune relance ne doit être possible tant que le document n’a pas été envoyé au client.

Intention : disposer d’un véritable tableau de pilotage des documents permettant de comprendre en quelques secondes où en est chaque pièce et quelle action peut être réalisée.

Gêne : l’interface actuelle oblige à interpréter plusieurs codes visuels et à rechercher les actions disponibles. elle peut également laisser apparaître des actions incohérentes avec l’état réel d’un document.

/espace-ingenieur/conformité

Problème : une section récapitule les documents pédagogiques joints alors que ceux-ci viennent déjà d’être sélectionnés dans l’interface.

Attendu : supprimer cette répétition ou intégrer les documents pédagogiques directement dans le même tableau récapitulatif que les autres éléments du pack.

Intention : éviter les doublons d’information et conserver une seule source de vérité concernant le contenu de l’envoi.

Gêne : afficher une seconde fois les mêmes éléments augmente inutilement la longueur de la page et peut créer une confusion entre sélection et récapitulatif.

/espace-ingenieur/conformité

Problème : la mention indiquant le nombre de pièces sélectionnées prend de la place sans apporter d’information indispensable à la préparation du pack.

Attendu : supprimer cette mention. svpppp

Intention : alléger la zone d’action et conserver uniquement les informations utiles à la décision ou à l’envoi.

Gêne : le nombre de pièces sélectionnées est facilement déductible de la sélection elle-même et ajoute encore une information sur un écran déjà dense.

/espace-ingenieur/conformité

Problème : la formulation « pièces qui ne partiront pas » est peu élégante et les documents concernés peuvent malgré tout donner l’impression qu’ils restent sélectionnables ou envoyables.

Attendu : supprimer cette mention. les documents qui ne sont pas prêts doivent apparaître grisés et leur case de sélection doit être désactivée. ils ne doivent en aucun cas pouvoir être ajoutés à l’envoi tant que leur état ne le permet pas. une infobulle peut éventuellement expliquer pourquoi le document n’est pas encore disponible.

Intention : faire comprendre immédiatement quels documents peuvent réellement être intégrés au pack.

Gêne : la formulation actuelle est peu professionnelle et le maintien d’éléments apparemment sélectionnables crée un risque d’incompréhension ou d’erreur lors de l’envoi.

/espace-ingenieur/conformité

Problème : le tableau du pack présente actuellement beaucoup d’espace vide entre les informations relatives aux différentes pièces.

Attendu : resserrer les colonnes et réduire les espaces inutilisés afin de rendre le tableau plus compact. utiliser éventuellement l’espace ainsi libéré pour proposer une zone d’aperçu du document sélectionné. ajouter dans ce cas une action « aperçu » permettant d’afficher le document sans quitter l’écran de préparation du pack.

Intention : optimiser l’espace disponible et faciliter le contrôle des documents avant leur envoi.

Gêne : une grande partie de l’écran est aujourd’hui inutilisée alors que la visualisation d’un document constitue une action réellement utile à ce stade.

/espace-ingenieur/conformité

Problème : la page est très dense et ne permet pas suffisamment de distinguer les deux logiques proposées : envoyer séparément les différents éléments de contractualisation ou envoyer directement un pack complet.

Attendu : structurer visuellement la page autour de trois niveaux clairement identifiables : le rappel du parcours et de l’étape actuelle ; une section « envoi des éléments séparément » permettant d’envoyer individuellement les documents nécessaires ; une section « envoi du pack de contractualisation » permettant de préparer et envoyer l’ensemble en une seule action. chaque section doit être visuellement autonome et immédiatement identifiable.

Intention : faire comprendre instantanément à l’ingénieur les deux parcours possibles et lui permettre de choisir son mode d’action.

Gêne : dans la présentation actuelle, les différentes fonctionnalités se succèdent sans hiérarchie suffisante, ce qui oblige à analyser longuement la page avant de comprendre ce qu’il faut faire.

/espace-ingenieur/conformité

Problème : des mentions complémentaires apparaissent actuellement sous les éléments tels que DER, KYC/KAWSI, lettre de mission, etc.

Attendu : supprimer ces sous-mentions lorsqu’elles ne sont pas indispensables. si une précision particulière doit être conservée, privilégier une infobulle.

Intention : obtenir une liste de documents plus compacte et immédiatement lisible.

Gêne : les sous-textes répétés augmentent fortement la densité de cette page déjà chargée.

/espace-ingenieur/conformité

Problème : la rubrique « règlement des honoraires » et la mention « montant à définir » figurent dans la conformité alors qu’il ne s’agit pas d’un élément de conformité à proprement parler.

Attendu : supprimer cette rubrique de l’écran conformité et repositionner, si nécessaire, le suivi du règlement dans une rubrique adaptée à la contractualisation, à la facturation ou au suivi administratif.

Intention : ne pas mélanger le contrôle réglementaire et le suivi financier de la mission.

Gêne : la présence du règlement des honoraires dans cette étape brouille le périmètre de la conformité et complexifie inutilement l’écran.

/espace-ingenieur/conformité

Problème : le fil du processus présenté sur la page conformité utilise une représentation graphique différente de celle des autres étapes du parcours patrimonial. la présentation actuellement utilisée sur la conformité, avec des étapes plus sobres, paraît néanmoins plus professionnelle, plus lisible et davantage en phase avec la charte graphique.

Attendu : conserver ce modèle graphique comme référence et le généraliser aux autres étapes du parcours patrimonial : prospects, collecte et analyse documentaire, études en cours, études restituées et clients en suivi.

Intention : disposer d’un seul composant graphique pour représenter les six étapes du parcours.

Gêne : plusieurs représentations différentes d’un même parcours créent une rupture visuelle et donnent l’impression que les écrans ne font pas partie du même workflow.

/espace-ingenieur/conformité

Problème : l’écran conformité reprend actuellement des informations telles que la composition du couple, les enfants, le nombre de parts fiscales, ainsi que des éléments du type honoraires à définir ou délai de cinq semaines.

Attendu : supprimer ces informations de cet écran. la page conformité doit se concentrer sur les éléments nécessaires à la conformité et à la contractualisation.

Intention : recentrer chaque écran sur sa finalité propre.

Gêne : le mélange d’informations patrimoniales, commerciales et réglementaires rend la page plus dense et brouille la compréhension du processus.

/espace-ingenieur/conformité

Problème : la mention « génération des livrables réglementaires » apparaît dans cette page alors qu’elle n’apporte pas d’information opérationnelle utile.

Attendu : supprimer cette mention.svppppp

Intention : conserver uniquement les informations nécessaires à la réalisation de l’étape de conformité.

Gêne : elle ajoute un niveau de texte supplémentaire sans aider réellement l’ingénieur dans son action.

/espace-ingenieur/conformité

Problème : des précisions continuent d’apparaître sous certains chiffres ou indicateurs alors que cette logique a déjà été supprimée sur d’autres écrans.

Attendu : supprimer systématiquement les commentaires situés sous les indicateurs lorsque l’intitulé et la valeur suffisent à comprendre l’information. si une explication reste réellement nécessaire, la déplacer dans une infobulle accessible via un petit « i ». à généraliser à l’ensemble de la plateforme.

Intention : alléger les tableaux de bord et donner davantage de force aux indicateurs principaux.

Gêne : ces sous-textes multiplient les niveaux de lecture et finissent par rendre les écrans inutilement chargés.

/espace-ingenieur/conformité

Problème : plusieurs informations telles que « en attente », « 3 900 € TTC », « assigné » ou les différents statuts ne sont pas correctement centrées sous leurs intitulés de colonnes.

Attendu : appliquer une règle générale à tous les tableaux de la plateforme : les colonnes comportant des noms de personnes ou des intitulés textuels principaux restent alignées à gauche ; les statuts, montants, pourcentages, dates, paiements, actions et autres données synthétiques sont centrés dans leur colonne ; les titres de ces colonnes doivent eux-mêmes être centrés.

Intention : définir une véritable règle de mise en page commune à tous les tableaux.

Gêne : des alignements différents d’un tableau ou d’une colonne à l’autre nuisent fortement à la cohérence visuelle de la plateforme.

/espace-ingenieur/conformité

Problème : les éléments tels que DER, KYC/KAWSI, LM, etc. n’utilisent pas tous la même puce ou le même positionnement. certains utilisent un point, d’autres un petit triangle, et le texte se décale selon la longueur de l’intitulé.

Attendu : utiliser systématiquement le petit triangle latéral, qui paraît suffisamment clair et discret. positionner les triangles dans une colonne fixe afin que tous les intitulés commencent exactement au même niveau, quelle que soit leur longueur.

Intention : obtenir une lecture verticale propre et homogène des différentes étapes ou pièces.

Gêne : les décalages actuels donnent une impression de désordre graphique et rendent la lecture de la liste moins fluide.

/espace-ingenieur/conformité

Problème : la mention « cabinet paris étoile » apparaît dans l’espace de l’ingénieur patrimonial.

Attendu : supprimer cette mention lorsqu’elle est affichée dans l’espace personnel de l’ingénieur.

Intention : ne conserver que les informations utiles à l’utilisateur dans son environnement de travail.

Gêne : l’ingénieur sait déjà à quel cabinet il est rattaché. répéter cette information surcharge inutilement l’interface.

/espace-ingenieur/conformité

Problème : la mention « couple » continue d’apparaître dans certains tableaux, notamment au niveau de la conformité, alors que sa suppression avait déjà été demandée ailleurs.

Attendu : supprimer la mention « couple » dans tous les tableaux de la plateforme et généraliser cette règle à l’ensemble des écrans concernés. la présence d’une ou de deux personnes suffit à comprendre immédiatement la composition du foyer.

Intention : alléger l’affichage et supprimer une information redondante.

Gêne : la persistance de cette mention crée des incohérences entre les différents écrans et ajoute une information qui n’apporte rien à la lecture.

/espace-ingenieur/agenda

Problème : la légende du calendrier est actuellement prédéfinie avec différentes catégories et couleurs. or, les typologies de rendez-vous et les usages peuvent varier d’un ingénieur patrimonial à l’autre.

Attendu : permettre à chaque ingénieur de configurer depuis les paramètres du calendrier : le nom des catégories affichées dans la légende ; leur couleur ; éventuellement leur ordre d’affichage ; et leur association avec les différents types de rendez-vous. prévoir des valeurs par défaut afin que l’utilisateur ne soit pas obligé de tout configurer.

Intention : permettre à chaque ingénieur d’adapter visuellement son calendrier à son organisation réelle tout en conservant une base commune.

Gêne : une légende figée peut rapidement ne plus correspondre aux usages réels de l’utilisateur et limiter l’intérêt du code couleur dans le calendrier.

/espace-ingenieur/agenda

Problème : la mention « entretien initial » apparaît actuellement de façon très visible sur la page publique. pour le prospect, cette terminologie correspond principalement à notre organisation interne du parcours et n’apporte pas nécessairement d’information utile.

Attendu : supprimer cette mention de la zone de présentation si un seul type de rendez-vous public est proposé. si plusieurs types de rendez-vous peuvent être proposés au public, conserver uniquement des intitulés réellement compréhensibles pour le prospect.

Intention : ne présenter au prospect que les informations nécessaires à sa prise de rendez-vous et éviter d’exposer des notions relevant principalement du workflow interne.

Gêne : « entretien initial » décrit notre étape de processus davantage qu’il n’aide le prospect à comprendre ce qu’il va obtenir lors du rendez-vous.

/espace-ingenieur/agenda

Problème : la page publique de prise de rendez-vous remplit également une fonction de vitrine pour l’ingénieur patrimonial. aujourd’hui, elle présente essentiellement son identité et le formulaire de réservation, sans véritable espace de présentation personnalisable.

Attendu : prévoir dans les paramètres du calendrier une zone permettant à chaque ingénieur de personnaliser sa page publique. il devrait notamment être possible d’ajouter un texte libre de présentation ainsi que, si souhaité, des liens utiles : site internet, avis trustpilot, page de présentation du cabinet ou autres ressources. prévoir également la possibilité d’utiliser une photo professionnelle si celle-ci n’est pas déjà récupérée depuis le profil ou la signature de l’ingénieur.

Intention : faire de la page de réservation une véritable page d’accueil professionnelle et rassurante, et pas uniquement un outil technique de choix d’un créneau.

Gêne : un prospect peut arriver sur cette page sans avoir eu de contact préalable avec l’ingénieur. il est donc utile qu’il puisse immédiatement comprendre à qui il s’adresse et accéder à quelques éléments de réassurance.

/espace-ingenieur/agenda

Problème : les blocs du calendrier affichent actuellement plusieurs informations secondaires directement dans la vue agenda, par exemple « google agenda », « entretien initial », « visio », « prospect en ligne », etc. par ailleurs, lorsque plusieurs rendez-vous sont proches ou se chevauchent, leur positionnement ne semble pas respecter précisément les horaires. par exemple, un rendez-vous prévu à 11 h 15 apparaît visuellement plutôt vers 11 h 30.

Attendu : dans la vue principale, conserver uniquement les informations indispensables : horaire et intitulé principal du rendez-vous. placer les informations complémentaires dans une fiche apparaissant au survol ou au clic : type de rendez-vous, origine, modalité, participants, source google agenda, etc. corriger également le positionnement graphique des rendez-vous afin qu’un rendez-vous à 11 h 15 soit réellement positionné à 11 h 15, y compris lorsque plusieurs rendez-vous se chevauchent.

Intention : obtenir un calendrier immédiatement lisible tout en conservant l’accès aux informations détaillées lorsque l’utilisateur en a besoin.

Gêne : l’accumulation d’informations surcharge les blocs et les problèmes de positionnement peuvent donner une perception erronée des horaires réels.

/espace-ingenieur/agenda

Problème : les pictogrammes « i » correspondant aux infobulles n’utilisent pas tous la même couleur. certains apparaissent en gris, d’autres en jaune.

Attendu : définir un style unique pour toutes les infobulles de la plateforme. je privilégierais un pictogramme gris, plus discret, puisqu’il s’agit d’une information secondaire et non d’une action principale. à généraliser à l’ensemble de la plateforme.

Intention : créer un langage graphique cohérent pour toutes les informations contextuelles.

Gêne : des couleurs différentes pour une même fonction peuvent laisser penser que les infobulles n’ont pas toutes le même rôle ou le même niveau d’importance.

/espace-ingenieur/agenda

Problème : le lien public généré pour l’agenda comporte actuellement une succession de chiffres et de zéros correspondant manifestement à un identifiant technique. ce lien est destiné à être transmis directement aux prospects et clients.

Attendu : générer une url publique courte, lisible et professionnelle, idéalement à partir du nom de l’ingénieur patrimonial ou d’un identifiant personnalisable. exemple de logique attendue : /rendez-vous/sarah-kaufmann plutôt qu’un identifiant technique composé de chiffres. si possible, permettre à l’ingénieur de personnaliser le libellé de son url dans les paramètres du calendrier.

Intention : disposer d’un lien suffisamment propre pour être intégré dans une signature d’e-mail, un site internet, un message ou tout autre support de communication.

Gêne : une url comportant de longs identifiants techniques donne une impression peu professionnelle et est difficile à mémoriser, à relire ou à transmettre.

/espace-ingenieur/agenda

Problème : la mention « agenda relié » fonctionne bien comme un bouton permettant d’accéder aux informations de liaison de l’agenda. en revanche, son apparence normale ne permet pas immédiatement de comprendre qu’il s’agit d’un élément cliquable : le comportement de bouton apparaît surtout au survol.

Attendu : conserver le principe actuel mais afficher l’élément comme un véritable bouton même hors survol, avec un contour clairement visible. remplacer le point actuel par une coche verte accompagnée de la mention « agenda relié ». au survol, prévoir simplement une légère surbrillance pour confirmer que le bouton est actionnable. le clic doit continuer à renvoyer vers la gestion ou les paramètres de connexion de l’agenda.

Intention : permettre de comprendre immédiatement que l’agenda est correctement synchronisé et que cette information donne également accès à sa configuration.

Gêne : dans son état actuel, l’élément ressemble davantage à un simple statut qu’à une action disponible, alors qu’il est effectivement cliquable.

/espace-ingenieur/modifications

Problème : une petite puce apparaît devant chaque dossier dans la rubrique « échéances dépassées », avec des variations de couleur très légères dont la signification n’est pas identifiable.

Attendu : si la puce est conservée, utiliser une couleur unique pour l’ensemble des dossiers. ne prévoir plusieurs couleurs que si elles correspondent à une règle métier explicite et immédiatement compréhensible.

Intention : conserver éventuellement un repère visuel simple sans introduire de pseudo-code couleur inutile.

Gêne : des variations de couleur laissent supposer l’existence de niveaux de priorité ou de statuts différents alors qu’aucune signification n’est expliquée.

/espace-ingenieur/modifications

Problème : le symbole « € » utilisé à côté du chiffre d’affaires semble utiliser une police ou un rendu différent de celui du montant.

Attendu : utiliser exactement la même typographie, graisse et taille visuelle pour le montant et son symbole monétaire.

Intention : uniformiser l’affichage des données financières.

Gêne : la différence typographique entre le nombre et son unité attire inutilement l’œil et donne l’impression que les deux éléments ont été assemblés avec des styles différents.

/espace-ingenieur/modifications

Problème : les informations telles que « 9 études en cours », « 4 échéances dépassées », « aucun rendez-vous à venir » ou la note de qualité du portefeuille utilisent actuellement des formats visuels différents.

Attendu : définir un format unique pour ces indicateurs : même forme, même typographie, même hauteur et même logique de positionnement. utiliser par défaut une couleur commune, par exemple le bleu. conserver une couleur spécifique uniquement lorsqu’elle véhicule une véritable information fonctionnelle : les échéances dépassées peuvent par exemple rester dans une couleur d’alerte.

Intention : créer un langage visuel commun pour tous les compteurs secondaires du tableau de bord.

Gêne : des informations de même niveau hiérarchique présentées avec des styles différents donnent l’impression qu’elles n’ont pas la même fonction ou la même importance.

/espace-ingenieur/modifications

Problème : les lignes du tableau utilisent actuellement une alternance de couleurs de fond.

Attendu : utiliser un fond homogène pour l’ensemble des lignes et conserver uniquement les séparateurs, espacements ou effets de survol nécessaires pour distinguer les entrées.

Intention : alléger l’interface et conserver une présentation plus sobre.

Gêne : l’alternance de couleurs peut être utile dans un tableau très dense, mais les lignes sont ici suffisamment hautes et espacées. elle ajoute donc davantage de bruit visuel qu’elle n’améliore la lecture.

/espace-ingenieur/modifications

Problème : la colonne « actions » comporte actuellement un bouton « ouvrir ». le terme est peu précis et l’action semble en partie redondante avec la possibilité de cliquer directement sur la ligne ou le client.

Attendu : remplacer les verbes d’action par des pictogrammes, conformément à la logique retenue sur le reste de la plateforme. si plusieurs actions sont utiles, conserver la colonne avec par exemple : un œil pour accéder à la fiche ou au dossier client ; un pictogramme spécifique représentant l’étude patrimoniale pour accéder directement à l’étude en cours.

Intention : Harmoniser l'aspect graphique de la plateforme

Gêne : un bouton générique « ouvrir » ne permet pas de savoir clairement ce qui va être ouvert et ajoute une action qui peut faire doublon avec d’autres éléments cliquables.

/espace-ingenieur/modifications

Problème : les intitulés et contenus des colonnes ne suivent pas toujours une règle d’alignement cohérente. certaines données numériques ou actions sont notamment alignées comme du texte.

Attendu : généraliser les règles suivantes à l’ensemble de la plateforme : centrer les titres de colonnes ; conserver les contenus textuels descriptifs alignés à gauche, notamment les noms de clients ; centrer les données numériques, pourcentages, montants et indicateurs courts ; centrer également les actions et leurs pictogrammes. sur ce tableau, les colonnes « avancement », « honoraires » et « actions » doivent notamment être centrées.

Intention : définir une règle graphique homogène pour l’ensemble des tableaux de la plateforme.

Gêne : des alignements différents d’un tableau ou d’une colonne à l’autre nuisent à la lisibilité et donnent une impression d’incohérence graphique.

/espace-ingenieur/modifications

Problème : plusieurs blocs du tableau de bord ne sont pas alignés entre eux : « études prioritaires », « prochains rendez-vous », « échéances dépassées », « qualité du portefeuille », les indicateurs du haut et la barre de recherche ne suivent pas toujours les mêmes axes.

Attendu : revoir la grille générale de mise en page afin que les différents blocs partagent des alignements verticaux cohérents. notamment : aligner « études prioritaires » avec « prochains rendez-vous » ; aligner « échéances dépassées » avec « qualité du portefeuille » ; faire correspondre ces blocs avec la grille des indicateurs située au-dessus ; aligner également la barre de recherche sur cette même grille. la suppression de certaines colonnes du tableau peut permettre d’ajuster plus facilement les largeurs.

Intention : donner au tableau de bord une structure visuelle plus rigoureuse et professionnelle.

Gêne : les décalages de largeur et d’alignement donnent une impression de construction par blocs indépendants plutôt que d’interface structurée autour d’une grille commune.

/espace-ingenieur/modifications

Problème : la rubrique « échéances dépassées » indique actuellement, sous chaque dossier, un pourcentage de complétude comme « dossier complété à 0 % ». cette information mesure un avancement, pas un dépassement de délai.

Attendu : faire apparaître en priorité une information temporelle calculée automatiquement, par exemple : « délai de collecte dépassé de 3 jours » puis, éventuellement en information complémentaire : « dossier complété à 40 % » le délai doit être calculé à partir de la date de début de l’étape et du délai cible défini pour celle-ci.

Intention : permettre à l’ingénieur d’identifier immédiatement depuis combien de temps une échéance est dépassée, tout en conservant si nécessaire l’état d’avancement du dossier.

Gêne : un pourcentage de complétude ne permet pas de comprendre pourquoi le dossier apparaît parmi les échéances dépassées ni depuis combien de temps une action est en retard.

/espace-ingenieur/modifications

Problème : la rubrique est intitulée « études prioritaires », mais certaines lignes apparaissent actuellement en étape 02 « conformité » ou étape 03 « collecte ». par définition, une étude en cours de production devrait se situer à l’étape 04. la colonne « étape » devient donc inutile si la population affichée dans ce tableau est correctement filtrée.

Attendu : n’afficher dans « études prioritaires » que les dossiers réellement entrés en phase d’étude. supprimer ensuite la colonne « étape », puisque tous les dossiers présents dans ce tableau seront nécessairement dans la même phase du parcours.

Intention : rendre cohérents le périmètre du tableau et les dossiers qu’il contient, tout en supprimant une colonne devenue redondante.

Gêne : la présence de dossiers encore en conformité ou en collecte dans un tableau d’études prioritaires brouille la compréhension du workflow et donne l’impression que plusieurs étapes différentes correspondent à une étude en cours.

/espace-ingenieur/modifications

Problème : sous le nom du client apparaissent actuellement plusieurs informations techniques, notamment le numéro de dossier ainsi qu’une mention relative à l’étape du parcours, par exemple « conformité », « collecte » ou « production ».

Attendu : supprimer ces informations de ce tableau afin de ne conserver que le nom du ou des clients. vérifier néanmoins que le numéro de dossier reste accessible dans la fiche client ou dans une zone dédiée du dossier si cette référence doit être conservée pour des besoins internes.

Intention : faire de la rubrique « études prioritaires » un véritable tableau de pilotage synthétique, sans informations techniques secondaires.

Gêne : ces données alourdissent chaque ligne alors qu’elles ne sont pas nécessaires à la lecture quotidienne du tableau de bord.

/espace-ingenieur/bord

Problème : dans la colonne client, les initiales apparaissent dans un cercle avant le nom du client. cette information n’apporte pas de valeur particulière et complexifie davantage l’affichage lorsqu’un dossier concerne un couple.

Attendu : supprimer les initiales et leur cercle associé. afficher directement le ou les noms des clients.

Intention : alléger visuellement le tableau et concentrer l’affichage sur les informations réellement utiles.

Gêne : les initiales sont redondantes avec les noms affichés juste à côté et ajoutent un élément graphique supplémentaire sans faciliter l’identification du dossier.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/43c9a593-c457-4092-8598-249a4807fc10

Problème : Actuellement, le pack de contractualisation est envoyé au client sous la forme de fichiers PDF joints au mail. Le client doit donc, en dehors de la plateforme : télécharger les documents ; les signer ; les renvoyer à l’ingénieur patrimonial ; éventuellement recommencer si un document est incomplet ou mal signé. La fiche conformité prévoit pourtant déjà, dans l’encart « Conditions de passage à l’étape 03 – Collecte et analyse documentaire », le suivi des conditions suivantes : DER daté et signé par le client ; KYC daté et signé par le client ; lettre de mission datée et signée par les deux parties ; règlement des honoraires reçu. Ces conditions restent affichées « En attente », mais le parcours actuel ne permet ni de recueillir les signatures directement depuis la plateforme, ni de mettre automatiquement à jour leur statut. Cette absence de fonctionnalité bloque également le recettage des étapes suivantes : tant que les signatures ne peuvent pas être validées, le dossier ne peut pas basculer à l’étape 3.

Attendu : L’envoi du pack de contractualisation devrait déclencher un parcours de signature électronique sécurisé depuis la plateforme. Le mail adressé au client devrait contenir un lien personnel lui permettant de : consulter les documents ; télécharger une copie s’il le souhaite ; signer électroniquement les documents concernés ; suivre les documents signés et restant à signer ; recevoir une confirmation à la fin du parcours. Les documents pédagogiques ou informatifs resteraient accessibles en lecture seule et ne nécessiteraient pas de signature. Gestion des signataires Pour un couple, la plateforme doit suivre distinctement chaque signataire et chaque document : DER : signature du ou des clients concernés ; KYC : signature des deux cocontractants lorsque requise ; lettre de mission : signature des clients puis de l’ingénieur patrimonial ; identification précise du signataire encore en attente. Un document ne doit être considéré comme intégralement signé que lorsque toutes les signatures requises ont été recueillies. Mise à jour des statuts Les statuts devraient évoluer automatiquement, par exemple : à signer ; signature en cours ; signé par le premier client ; signé par le second client ; signé par tous les clients requis ; en attente de signature de l’ingénieur ; signé par toutes les parties ; à contrôler ; validé ; à reprendre. La version définitive signée doit être enregistrée dans le dossier et consultable par l’ingénieur patrimonial. Contrôle par l’ingénieur patrimonial L’ingénieur doit pouvoir : consulter le document signé ; contrôler les signatures, les dates et les informations ; valider le document ; demander une reprise ou une nouvelle signature ; relancer uniquement le signataire concerné. Le bouton « Ouvrir l’espace sécurisé – étape 03 » ne doit devenir disponible que lorsque toutes les conditions réelles de passage sont satisfaites. Solution temporaire nécessaire pour le recettage Dans l’attente du développement complet de la signature électronique, il est nécessaire d’ajouter un outil temporaire permettant à l’ingénieur patrimonial de simuler la validation des signatures afin de poursuivre les tests des étapes suivantes. Cette solution temporaire ne constitue pas la résolution du présent ticket. Le ticket doit rester ouvert jusqu’à la mise en place du véritable parcours de signature électronique. Fonctionnement temporaire attendu Pour chaque document et chaque signataire requis, l’ingénieur patrimonial doit disposer d’une action explicite, par exemple : Marquer comme signé pour recette – signature fictive Cette action doit permettre de simuler séparément : la signature du premier client ; la signature du second client ; la signature de l’ingénieur patrimonial ; la validation finale du document. Une fois toutes les signatures fictives requises renseignées, les conditions de passage à l’étape 3 peuvent être considérées comme satisfaites uniquement pour permettre la poursuite du recettage. Identification obligatoire de la signature fictive Il doit être impossible de confondre cette validation temporaire avec une véritable signature électronique. Chaque document ou statut concerné doit afficher de manière très visible une mention telle que : SIGNATURE FICTIVE DE RECETTE — SANS VALEUR JURIDIQUE ou : Validé manuellement pour test — aucune signature électronique recueillie Cette mention doit apparaître : dans la carte du document ; dans le statut de la condition de passage ; dans l’historique du dossier ; lors de la consultation du document ; dans tout export ou récapitulatif qui pourrait laisser croire que le document est réellement signé. Le statut ne doit donc pas être simplement « Signé », mais par exemple : signature fictive client enregistrée ; signature fictive ingénieur enregistrée ; document validé pour recette uniquement. Traçabilité Chaque validation fictive doit enregistrer : l’identité de l’ingénieur ayant réalisé l’action ; la date et l’heure ; le document concerné ; le signataire simulé ; la mention qu’il s’agit d’une validation de recette sans valeur juridique. Une confirmation doit être demandée avant l’action, avec un message explicite : Cette action simule une signature uniquement pour permettre le recettage. Elle ne constitue pas une signature électronique et ne confère aucune valeur juridique au document. Encadrement de l’outil temporaire Cette fonctionnalité devrait être : réservée aux utilisateurs autorisés ; identifiée comme une fonction temporaire de recette ; désactivable par paramétrage ; retirée ou neutralisée lorsque le véritable parcours de signature sera disponible. Elle ne doit pas : produire une attestation de signature ; apposer une signature graphique ou électronique sur le PDF ; envoyer au client un document présenté comme légalement signé ; permettre de considérer le dossier comme contractuellement régularisé en dehors du contexte de recette.

Intention : À terme, centraliser et sécuriser la contractualisation dans la plateforme. À court terme, permettre la poursuite du recettage des étapes 3 et suivantes sans créer de confusion entre une véritable signature électronique et une validation fictive utilisée uniquement pour les tests.

Gêne : Sans solution temporaire, le parcours reste bloqué à l’étape conformité et les étapes suivantes ne peuvent pas être testées. À l’inverse, une simple validation manuelle affichée comme « signée » créerait un risque majeur de confusion. Il est donc indispensable que le caractère fictif, temporaire et dépourvu de valeur juridique soit visible à tout moment.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/43c9a593-c457-4092-8598-249a4807fc10

Problème : Le mail envoyé au client avec le pack de contractualisation ne reprend pas la signature de l’ingénieur patrimonial en charge du dossier. Dans le mail reçu, le corps du message se termine simplement par : Bien à vous, sans faire apparaître l’identité, la fonction, le cabinet ni les coordonnées de l’ingénieur patrimonial.

Attendu : Lors de l’envoi du pack de contractualisation, la signature professionnelle de l’ingénieur patrimonial rattaché au dossier doit être ajoutée automatiquement à la fin du mail. Elle doit reprendre les informations enregistrées dans son profil, notamment : prénom et nom ; fonction ; nom du cabinet ; adresse professionnelle ; adresse e-mail ; numéro de téléphone, s’il est renseigné ; tout autre élément prévu dans la signature paramétrée. La signature doit être ajoutée après le corps modifiable du message et ne doit pas nécessiter une ressaisie manuelle à chaque envoi. Elle doit également correspondre à l’ingénieur effectivement en charge du dossier, sans reprendre une signature générique ou celle d’un autre utilisateur.

Intention : Permettre au client d’identifier immédiatement son interlocuteur et assurer une présentation professionnelle et personnalisée du mail de contractualisation.

Gêne : L’absence de signature rend le message impersonnel et ne permet pas au client d’identifier clairement la personne à contacter en cas de question sur les documents reçus.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/43c9a593-c457-4092-8598-249a4807fc10

Problème : Dans la page Conformité, lorsqu’un ingénieur patrimonial ouvre le KYC, passe en mode « Modifier », puis modifie une donnée dans la rubrique « DCI complet », cette modification n’est pas répercutée dans la synthèse patrimoniale. Dans le test réalisé, la valeur de la résidence principale a été modifiée de : 290 000 € à 800 000 € Pourtant, après cette modification, la synthèse patrimoniale continue notamment d’afficher : un patrimoine brut de 450 574 € ; une valeur immobilière d’usage de 290 000 € ; les mêmes répartitions par classe d’actifs ; les mêmes totaux dans le tableau patrimonial. La modification semble donc enregistrée ou visible dans la partie éditable du DCI complet, mais elle n’alimente pas les calculs et restitutions de la synthèse patrimoniale.

Attendu : Lorsqu’une donnée patrimoniale est modifiée puis enregistrée depuis le KYC, la synthèse patrimoniale doit être automatiquement recalculée à partir de la nouvelle valeur. La mise à jour doit concerner tous les éléments dépendant de la donnée modifiée, notamment : le patrimoine brut ; le patrimoine net ; la répartition par classe d’actifs ; les montants et pourcentages des graphiques ; le patrimoine détenu par titulaire ; le détail patrimonial par actif ; les sous-totaux et totaux ; les ratios financiers calculés à partir du patrimoine ; toute autre restitution du KYC reposant sur cette donnée. Dans l’exemple présenté, le remplacement de 290 000 € par 800 000 € doit entraîner immédiatement le recalcul de la composante immobilière et du patrimoine global. La synthèse doit se mettre à jour : soit immédiatement après l’enregistrement ; soit après actualisation de la page ; mais sans conserver les anciennes valeurs. Si la modification n’a pas été enregistrée, un message doit l’indiquer clairement. L’interface ne doit pas laisser croire que la donnée a été modifiée alors que la synthèse continue de s’appuyer sur l’ancienne valeur.

Intention : Garantir que la synthèse patrimoniale repose toujours sur la dernière version validée des données du KYC.

Gêne : L’ingénieur patrimonial peut corriger une donnée sans que les agrégats, graphiques et indicateurs soient mis à jour. La synthèse devient alors incohérente avec le DCI complet et peut présenter des montants patrimoniaux erronés.

https://ingenieur.astraeos.fr/espace-ingenieur/conformite/43c9a593-c457-4092-8598-249a4807fc10

Problème : Dans la page Conformité, lorsqu’un ingénieur patrimonial ouvre le KYC, passe en mode « Modifier », puis accède à la rubrique « DCI complet », les champs correspondant à des montants monétaires ne bénéficient pas d’une mise en forme adaptée. Par exemple, la valeur estimée de la résidence principale apparaît sous la forme : 800000 au lieu d’un montant lisible exprimé en euros. D’autres montants sont également affichés sans séparateur de milliers, par exemple : 128032 € Le problème concerne les valeurs monétaires consultées ou modifiées directement depuis l’enveloppe KYC.

Attendu : Tous les champs ayant vocation à recueillir ou afficher une somme d’argent doivent bénéficier automatiquement d’une présentation monétaire homogène, notamment : 800 000 € 128 032 € 32 512 € Cette mise en forme doit s’appliquer : à l’ouverture du KYC ; dans le mode « Modifier » ; pendant la saisie ou au plus tard à la sortie du champ ; après l’enregistrement des modifications ; lors d’une nouvelle consultation du document ; dans toutes les rubriques du DCI complet reprises dans le KYC. La correction doit concerner l’ensemble des champs monétaires : valorisation des actifs, patrimoine financier, emprunts, revenus, charges et plus généralement toute donnée exprimée en euros. La mise en forme visuelle ne doit pas altérer la valeur numérique enregistrée ni empêcher sa modification.

Intention : Améliorer la lisibilité des montants et garantir une présentation homogène des données patrimoniales dans le KYC.

Gêne : L’absence de séparateur de milliers et, selon les champs, du symbole « € » rend les montants difficiles à lire et augmente le risque d’erreur de contrôle ou de modification par l’ingénieur patrimonial.

https://app.astraeos.fr/parcours/dci-complet?prospect=tristan-langlois-f681d34b&name=Tristan%20LANGLOIS

Problème : Lorsqu’un prospect reprend un DCI complet déjà commencé, l’étape de reprise peut s’afficher correctement avec les réponses précédemment enregistrées. Ce bug semble être apparu suite à la résolution du ticket 401. En revanche, dès qu’il clique sur « Continuer », les étapes suivantes peuvent ne plus charger leur contenu. L’en-tête, le numéro de l’étape, la barre de progression ainsi que les boutons « Précédent » et « Continuer » restent visibles, mais toute la zone centrale du questionnaire est vide. Aucun titre, champ ou bloc de saisie n’apparaît. Dans le test présenté, le problème est apparu après une reprise à l’étape 8 sur 22, puis sur les étapes 9, 10 et suivantes. Toutefois, le dysfonctionnement ne semble pas propre à l’étape 8 : il peut survenir après la reprise du DCI complet, quelle que soit l’étape à laquelle le prospect reprend son parcours.

Attendu : Après la reprise d’un DCI complet, la navigation vers toutes les étapes suivantes doit fonctionner normalement. Chaque clic sur « Continuer » doit charger l’étape correspondante avec : son titre et ses textes explicatifs ; l’ensemble de ses champs et sections ; les données éventuellement déjà enregistrées ; les boutons et actions propres à cette étape. La correction doit s’appliquer quelle que soit l’étape de reprise du questionnaire. Si une erreur de chargement survient, l’interface doit afficher un message explicite et proposer une action permettant de réessayer ou de reprendre le parcours, plutôt que de laisser une page vide. Étapes de reproduction Commencer à remplir un DCI complet. Quitter le questionnaire à n’importe quelle étape. Rouvrir le lien personnel du DCI complet. Reprendre le parcours à l’étape proposée. Cliquer sur « Continuer ». Constater que le contenu de l’étape suivante, puis éventuellement des suivantes, ne s’affiche pas.

Intention : Permettre au prospect de reprendre un DCI complet en cours et de poursuivre normalement le questionnaire jusqu’à son terme, quelle que soit l’étape de reprise.

Gêne : Ce dysfonctionnement bloque totalement la poursuite du DCI complet après sa reprise. Même lorsque les données antérieures semblent avoir été retrouvées, le prospect ne peut plus accéder aux étapes suivantes et terminer le questionnaire.