Family Office : infrastructure technologique, construire ou subir la dérive ?

Le problème, c'est l'accumulation, pas l'ambition

Lorsqu'un family office est mis en place, les premières décisions technologiques sont prises sous la pression : l'équipe est réduite, les actifs sont en mouvement, et la priorité est de produire les rapports plutôt que de concevoir la manière dont ils seront élaborés. Un système de comptabilité de portefeuille est mis en place sous licence. Un dépositaire fournit un flux de données. Quelqu'un élabore un modèle de consolidation dans un tableur, car le système comptable ne peut pas encore prendre en charge d'autres solutions. En l'espace de deux ans, ce tableur présente des dépendances, un historique des versions que personne ne comprend, et un responsable désigné qui est la seule personne capable d'effectuer la clôture de fin de mois. Il ne s'agit pas de négligence. C'est le résultat prévisible de la résolution de problèmes immédiats sans cadre structurel.

Il en résulte ce que les professionnels appellent la « dérive technologique » : une pile qui n'a jamais été conçue comme un tout et qui, de ce fait, ne fonctionne comme un tout que de manière intermittente. Une enquête réalisée en 2023 par un grand réseau de dépositaires a révélé qu'environ 60 % des single family offices disposant d'actifs supérieurs à $500M déclaraient utiliser plus de huit sources de données distinctes pour leur reporting consolidé. Moins de la moitié de ces sources étaient reliées par un contrat de données formel. L'autre moitié faisait l'objet d'un rapprochement manuel, généralement mensuel, effectué par un membre de l'équipe financière ou opérationnelle. Ce temps de rapprochement s'élevait en moyenne à 14 heures par cycle de reporting, ce qui, en coûts complets, représente une dépense opérationnelle significative et récurrente qui figure rarement dans une ligne budgétaire.

Les quatre couches indispensables à toute pile de family office

Une infrastructure technologique performante ne se définit pas par son composant le plus sophistiqué. Elle se définit par la présence de quatre couches distinctes, dont la responsabilité est clairement attribuée : l'ingestion des données, un référentiel de données de référence, une couche d'analyse et de reporting, ainsi qu'une couche de governance et d'audit. Les services qui rencontrent des difficultés en matière de fiabilité des rapports ont presque toujours omis au moins l'une de ces couches, ou ont laissé deux d'entre elles se fondre en un seul outil qui ne remplit correctement aucune des deux fonctions.

Première couche : ingestion des données

L'ingestion des données couvre tous les canaux par lesquels les informations externes entrent dans la pile. Cela inclut les flux des dépositaires (généralement transmis sous forme de messages SWIFT MT ou ISO 20022, ou via une API propriétaire), les rapports de valeur liquidative des administrateurs de fonds, les évaluations des investissements directs, les fichiers de transactions bancaires et les flux de documents fiscaux. Le principe essentiel à ce niveau est l'immuabilité : les données brutes reçues d'une source doivent être stockées exactement telles qu'elles ont été reçues, accompagnées d'un horodatage et d'un identifiant de source, avant que toute transformation ne soit appliquée. Cette règle unique élimine toute une catégorie de litiges liés au rapprochement, car elle permet de distinguer une erreur à la source d'une erreur de transformation au sein du service.

Deuxième couche : le référentiel « golden record »

Le référentiel « golden record » constitue la représentation unique et faisant autorité des positions, des valorisations, des transactions et des relations entre entités à un moment donné. C'est la couche que la plupart des family offices n'ont jamais formellement définie. Sans elle, chaque rapport en aval effectue implicitement ses propres choix quant à la source à retenir lorsque les sources divergent, et ces choix sont rarement documentés. Le référentiel de données de référence nécessite un dictionnaire de données : une spécification formelle de chaque champ, de ses valeurs autorisées, de sa hiérarchie des sources (quelle source prévaut en cas de conflit) et de sa fréquence de mise à jour. Ce dictionnaire doit être établi avant de choisir les outils, et non l'inverse. La plupart des projets de consolidation échouent parce que le dictionnaire est élaboré a posteriori, par ingénierie inverse de ce que le système retenu est capable de prendre en charge.

Troisième couche : analyse et reporting

La couche analytique exploite le référentiel de données de référence et génère des rapports d'attribution de performance, d'agrégation des risques, de prévision de cash flows et des rapports destinés aux clients. La règle fondamentale ici est que cette couche doit être en lecture seule par rapport au référentiel de données de référence. Les analystes et les professionnels de l'investissement ne doivent en aucun cas pouvoir modifier les données de référence depuis un outil de reporting. Dans la pratique, cette règle est constamment enfreinte, et chaque infraction est à l'origine d'un système parallèle. Lorsqu'un analyste constate que l'outil de reporting ne permet pas d'effectuer un calcul spécifique, sa réaction naturelle est d'exporter les données vers un tableur. Si le résultat est ensuite présenté comme faisant autorité, le service se retrouve avec deux versions concurrentes de la vérité.

Quatrième couche : governance et audit

La couche de governance et d'audit permet de déterminer qui a modifié quoi, quand et sous l'autorisation de qui. Dans la plupart des cas, il ne s'agit pas d'une application distincte, mais d'un ensemble de règles appliquées de manière cohérente aux trois autres couches. Les journaux d'accès, les journaux de modification, les workflows d'approbation des dérogations en matière d'évaluation et un registre formel des exceptions relatives à la qualité des données relèvent tous de cette couche. Elle n'est pas facultative pour les services soumis à des obligations de déclaration au titre de FATCA ou du CRS, qui exigent tous deux des pistes d'audit vérifiables pour les données financières au niveau de l'entité. Le deuxième pilier du BEPS ajoute une dimension supplémentaire : le régime d'impôt minimum mondial de 15 % exige une répartition des revenus par juridiction avec un niveau de détail que les systèmes fondés sur des tableurs ne peuvent structurellement pas prendre en charge avec la qualité d'audit attendue par les régulateurs.

Une structure dépourvue de couche de governance explicite n'est pas seulement fragile sur le plan opérationnel. Elle constitue un risque réglementaire qui s'accroît à chaque juridiction que la famille ajoute à sa structure.

Pourquoi les systèmes parallèles apparaissent-ils, et pourquoi persistent-ils ?

Les systèmes parallèles ne constituent pas un échec technologique. Ils sont un signal d'alerte. Ils apparaissent, immanquablement, dans les 18 à 24 mois suivant le déploiement de tout nouveau système, parce que le système central n'a pas répondu à un besoin spécifique des utilisateurs et qu'aucune personne disposant de l'autorité nécessaire n'a remédié à la situation. L'utilisateur comble cette lacune avec les outils à sa disposition, ce qui se traduit presque toujours par un tableur. Ce tableur fonctionne. On en vient à s'y fier. Il gagne en complexité. La personne qui l'a créé quitte l'entreprise ou change de poste, et le tableur devient ce que le secteur appelle une « dépendance vis-à-vis d'une personne clé », dotée d'une extension de fichier.

La persistance des systèmes parallèles obéit à une logique cohérente. La mise hors service d'un système parallèle nécessite de reconnaître qu'il contient des données faisant autorité, de migrer ces données vers le référentiel de données de référence, de reproduire sa logique dans le système central et de convaincre l'équipe que le système central répond désormais au besoin auquel le système parallèle répondait auparavant. Chacune de ces étapes comporte un coût et un risque. Le système parallèle, en revanche, ne génère aucun coût supplémentaire de fonctionnement. Pour un trimestre donné, le choix rationnel est de ne pas y toucher. Sur plusieurs années, ces choix individuellement rationnels produisent un résultat collectivement irrationnel : une architecture comportant plusieurs sources de vérité concurrentes, dont aucune ne peut être considérée comme entièrement fiable.

Fragilité des intégrations et surface de rupture

Les intégrations point à point entre systèmes constituent le tissu conjonctif de la plupart des piles de family office, et représentent la source la plus courante de défaillances silencieuses. Une connexion point à point se compose généralement d'un transfert de fichiers, d'un script et d'une hypothèse concernant le format. Cette hypothèse est documentée, si tant est qu'elle le soit, dans le script lui-même. Lorsque le système source modifie son format de sortie, ce que les fournisseurs font périodiquement et avec un préavis variable, , le script échoue. Si la défaillance est manifeste (message d'erreur, fichier manquant), elle est rapidement détectée. Si elle est silencieuse (un champ change de position dans un fichier plat et le script continue de s'exécuter mais associe désormais la mauvaise valeur au mauvais champ), elle peut ne pas être détectée avant un audit ou un contrôle client.

Chaque connexion point à point supplémentaire ajoutée sans contrat de données formel double approximativement la surface de défaillance attendue pour ce nœud, car chaque connexion dépend de la stabilité de sa source et de celle de toutes les autres connexions qui alimentent la même cible en aval. Un service disposant de douze sources de données et de vingt intégrations ne gère pas vingt risques d'intégration de manière isolée ; il gère un réseau de dépendances dont les modes de défaillance interagissent. La solution pratique ne consiste pas à réduire le nombre de sources de données, ce qui est souvent irréalisable, , mais à mettre en place des contrats de données : des accords formels et versionnés précisant le schéma, la fréquence de mise à jour et le protocole de gestion des erreurs pour chaque flux. Les contrats de données font passer les défaillances d'intégration de silencieuses à manifestes, et d'ambiguës à identifiables.

Note sur les flux de données des dépositaires et des administrateurs de fonds

La qualité et le niveau de détail des flux de données fournis par les dépositaires varient considérablement. Un flux provenant d'un courtier principal comprend généralement des détails au niveau des transactions, les revenus courus et les frais de financement. Un flux provenant d'une banque privée peut ne fournir que des récapitulatifs de positions en fin de journée. Les rapports sur la valeur liquidative fournis par les administrateurs de fonds sont souvent transmis sous forme de fichiers PDF ou de tableurs structurés plutôt que sous forme de fichiers lisibles par machine, ce qui nécessite une étape d'extraction manuelle ou semi-automatisée susceptible d'introduire ses propres sources d'erreur. Les services gérant des allocations importantes en marchés privés devraient prévoir explicitement dans leur budget le coût de l'extraction des données provenant de sources non standardisées, et devraient négocier, au moment de la souscription au fonds, l'accès à des flux lisibles par machine lorsque l'administrateur est en mesure de les fournir.

Governance à titre préventif : le comité technologique

Le mécanisme le moins coûteux pour prévenir toute dérive technologique future consiste à mettre en place un comité de governance technologique qui se réunit chaque trimestre et comprend au moins un responsable des investissements, aux côtés du directeur des opérations et du directeur financier. Le mandat de ce comité est précis : examiner les anomalies de qualité des données du trimestre écoulé, approuver toute nouvelle source de données ou intégration avant son ajout à l'infrastructure, et évaluer les systèmes parallèles mis en évidence par l'équipe. La présence du responsable des investissements n'est pas purement symbolique. Les décisions d'investissement découlent de la qualité des données, et son implication instaure une responsabilité directe entre la couche technologique et les décisions qu'elle sous-tend.

Le comité doit tenir à jour un registre technologique : un document unique répertoriant chaque système, chaque intégration, chaque source de données, ainsi que le nom du responsable de chacun d'entre eux. Ce registre n'est ni un plan de projet ni une feuille de route. Il s'agit d'une cartographie de l'état actuel. Les services qui n'en ont jamais établi un sont généralement surpris de découvrir le nombre de connexions existantes et le peu d'entre elles qui ont un responsable désigné. Le simple fait d'établir ce registre met en évidence les priorités d'action les plus urgentes, sans nécessiter aucune évaluation externe.

Le registre technologique est l'équivalent, dans le cadre du family office, d'un inventaire physique : sa gestion ne coûte presque rien et constitue la condition préalable à toute amélioration significative de la pile.

Séquencer correctement un projet de consolidation

Pour les services qui ont constaté que la dérive accumulée est devenue ingérable, un projet de consolidation constitue la réponse appropriée. La séquence comporte trois phases. La première est définitionnelle : établir le dictionnaire de données, répertorier toutes les sources et intégrations existantes, identifier l'ensemble des systèmes parallèles et s'accorder sur une hiérarchie des sources pour chaque type de données en conflit. Cette phase devrait durer entre quatre et huit semaines et aboutir à un cahier des charges écrit, et non à une présentation PowerPoint. La deuxième phase est architecturale : sélectionner ou configurer les outils permettant de mettre en œuvre le référentiel de données de référence tel que défini dans le cahier des charges. C'est le cahier des charges qui détermine le choix des outils ; ce n'est pas le choix des outils qui modifie le cahier des charges. La troisième phase est celle de la migration : transférer les données, reproduire la logique des systèmes parallèles, effectuer une validation par rapport à l'état antérieur et mettre officiellement hors service chaque composant hérité.

L'erreur la plus courante dans les projets de consolidation consiste à raccourcir ou à sauter la première phase, parce que l'équipe est impatiente de voir le nouveau système fonctionner. Un système configuré avant que le dictionnaire de données ne soit complet sera conçu pour s'adapter aux contraintes de la situation actuelle plutôt que pour répondre aux besoins de la situation cible. Il en résulte un nouveau système qui reproduit les problèmes structurels de l'ancien, à un coût considérable, et avec une équipe désormais réticente à tout nouvel effort de consolidation pendant plusieurs années. La première phase n'est pas une charge supplémentaire. C'est le cœur du travail.