Le volume, la comptabilité profonde, la maîtrise technique et l'IA. Quatre défis qui ne se remplacent pas : ils s'additionnent.
Tous les articlesQuand on évalue un logiciel de syndic, on regarde des écrans : un solde, un appel de fonds, un relevé de compte, les annexes d'assemblée générale. C'est légitime, ce sont eux qu'on utilisera tous les jours. Mais ces écrans ne sont que la partie émergée. Dessous tourne un moteur comptable, et c'est lui qui décide si le logiciel tient la charge, si les comptes sont justes au centime, et si l'outil reste rapide le jour où toutes les copropriétés appellent leurs fonds en même temps.
Le plus gros problème à résoudre dans un logiciel de gestion de syndic, c'est la comptabilité. C'est le morceau qui concentre le plus de difficulté et le plus de technicité. Nous l'avons construit. Cet article décrit ce qu'il a fallu réunir, en quatre défis qui ne se remplacent pas les uns les autres : ils s'additionnent.
Un logiciel pensé pour une copropriété de dix lots fonctionne. En démonstration, il est même impeccable. Il cède dès que la charge réelle arrive, parce qu'il ne correspond pas à la réalité du terrain : des centaines de syndics, chacun avec des dizaines de copropriétés, sur une seule et même plateforme.
La conséquence n'est pas seulement technique, elle est économique. Le modèle d'un éditeur repose sur la multiplication des clients. Un moteur qui ne tient pas la charge interdit la croissance commerciale : chaque nouveau syndic signé aggrave le problème au lieu de le financer.
La volumétrie d'un moteur comptable de syndic est le produit d'une chaîne où chaque niveau multiplie le précédent :
Aux heures creuses, une route large paraît surdimensionnée. À l'heure de pointe, seule celle qui a été calculée pour le pic reste praticable. On ne dimensionne pas une route pour la moyenne ; un logiciel de syndic non plus.
En pratique, cela veut dire raisonner sur le cas le plus chargé et jamais sur la moyenne, prévoir le plus gros syndic et la plus grosse copropriété du marché, tester la plateforme sous la charge maximale réaliste, et garder une marge pour la croissance des clients.
En copropriété, le pic n'est pas un accident : il est inscrit au calendrier. Les appels de fonds trimestriels tombent aux mêmes dates pour la quasi-totalité des copropriétés, le 1er janvier, le 1er avril, le 1er juillet et le 1er octobre. Toute la plateforme encaisse le choc au même moment. Les clôtures d'exercice et la saison des assemblées générales ajoutent une seconde vague de traitements lourds, à d'autres dates.
Le dimensionnement retenu par SyndiLibre (10 000 lots par copropriété, 1 000 copropriétés par syndic, 500 syndics sur une plateforme) dépasse largement la plus grosse copropriété réellement gérée. Cette marge n'est pas un excès de prudence : elle fait partie de la conception.
L'unité atomique de la gestion comptable, c'est le lot, quel que soit le nombre de lots que détient un copropriétaire. Quatre raisons l'imposent :
Sur chaque lot s'inscrivent les appels de provisions du budget prévisionnel, les encaissements, les cotisations au fonds travaux, les provisions pour travaux votés en assemblée, la répartition des factures selon les tantièmes, et la régularisation à la clôture.
Une dépense de 1 000 € sur une copropriété de 1 000 lots produit au moins 4 000 lignes : pour chaque lot, deux lignes d'écriture et deux lignes de gestion. Une facture n'a donc pas un montant unique dans la base. Elle en a autant que de lots concernés.
Chez SyndiLibre, cette répartition se fait au moment de la saisie : chaque facture enregistrée est aussitôt ventilée sur les lots, selon sa clé (charges générales, bâtiment, ascenseur…) et les tantièmes de chacun. C'est ce qui rend les soldes justes à tout instant, et c'est aussi ce qui fait exploser le nombre de lignes.
Prenons des hypothèses volontairement moyennes : 500 syndics, 50 copropriétés par syndic, 30 lots par copropriété, soit 750 000 lots gérés, et 4 lignes au minimum par opération.
| Lignes produites par exercice | Lignes |
|---|---|
| Budget de fonctionnement : 4 trimestres × 8 clés, par lot | 24 000 000 |
| Budget travaux : 4 trimestres × 1 clé, par lot | 3 000 000 |
| Appels de provisions, 4 par an et par lot | 12 000 000 |
| Appels du fonds travaux, 4 par an et par lot | 12 000 000 |
| Encaissements, environ 1 par appel | 24 000 000 |
| Factures : enregistrement et règlement, 120 par copropriété | 24 000 000 |
| Factures : répartition sur les 30 lots | 360 000 000 |
| Total par exercice | ≈ 459 millions |
Le milliard de lignes est dépassé dès le troisième exercice. En dix exercices, le volume dépasse 4,5 milliards. C'est un comptage minimal, sans métadonnées ni gestion accessoire, et sur des hypothèses moyennes : la réalité des gros syndics dépasse ces chiffres.
Un écran qui calcule fait attendre le gestionnaire ; un écran qui répond le laisse produire. La productivité exige que tout fonctionne vite, et cela suppose une architecture de données taillée pour le volume. Concrètement :
Trois raisons. D'abord, tout passe par le même goulot : saisies du pic trimestriel, répartitions, recherches et éditions se disputent les mêmes ressources, au même moment. Ensuite, les tables ne cessent de grossir : sur des centaines de millions de lignes, chaque index et chaque requête coûtent plus cher à chaque exercice ajouté. Enfin, les besoins sont de nature différente : chercher un texte, suivre un événement en temps réel ou comparer des documents ne relève pas du même moteur que tenir des écritures.
Au-delà de quelques centaines de millions de lignes, un système bien dimensionné répartit ses données sur plusieurs bases spécialisées. C'est le choix de SyndiLibre, où chaque type de donnée est confié au moteur conçu pour lui :
| Rôle | Moteurs |
|---|---|
| Stocker | PostgreSQL (base principale), MongoDB (documents), Cassandra (données distribuées), SQL Server (reporting) |
| Chercher et relier | Elasticsearch (recherche), Neo4j (graphe des relations), Pinecone (vecteurs et sémantique) |
| Accélérer et diffuser | Redis (cache), RabbitMQ (événements et files), Firebase Realtime Database (temps réel) |
| Infrastructure | AWS : calcul et conteneurs, stockage et sauvegardes, CDN et pare-feu, observabilité, secrets et accès, livraison continue |
Une comptabilité de syndic ressemble à un spectacle de danse. Le gestionnaire est le spectateur : il voit la danse, c'est-à-dire les soldes, les appels, les relevés, les comptes d'assemblée générale. Les écritures et les comptes sont les danseurs : chacun doit être au bon endroit au bon moment. L'éditeur est le chorégraphe : il conçoit tout ce qui doit se passer pour que le spectateur voie la bonne danse.
Deux regards portent donc sur la même comptabilité. Le gestionnaire voit le solde d'un copropriétaire, un appel de fonds à envoyer, une facture à régler, des comptes à présenter. L'éditeur, lui, doit maîtriser les écritures en partie double derrière chaque action, les comptes de tiers, de charges, de produits et de trésorerie, l'équilibre permanent de l'ensemble, la clôture, la régularisation et le report des soldes, et enfin la sauvegarde et la protection des données.
Chaque opération s'écrit au moins deux fois : un débit et un crédit de même montant. La somme des débits égale toujours la somme des crédits. Les quatre opérations les plus courantes s'écrivent ainsi :
| Opération | Débit | Crédit |
|---|---|---|
| Appel de provisions | 450 Copropriétaire | 701 Provisions sur opérations courantes |
| Encaissement du copropriétaire | 512 Banque | 450 Copropriétaire |
| Facture fournisseur | 6xx Charges | 401 Fournisseur |
| Règlement du fournisseur | 401 Fournisseur | 512 Banque |
C'est un schéma simplifié. Dans un moteur tenu au lot, chaque écriture sur le compte 450 se démultiplie au niveau du lot.
La copropriété a son propre plan comptable, fixé par le décret du 14 mars 2005. La comptabilité y est d'engagement : une charge s'enregistre dès qu'elle est engagée, indépendamment de son paiement.
| Classe | Objet | Exemples |
|---|---|---|
1 | Provisions, avances, fonds | Avances des copropriétaires, fonds de travaux (compte 105) |
4 | Copropriétaires et tiers | 450 copropriétaires, 401 fournisseurs, autres tiers |
5 | Comptes financiers | 512 banque : le compte séparé du syndicat |
6 | Charges | Achats, services, entretien, travaux, honoraires |
7 | Produits | 701 provisions sur opérations courantes, 702 provisions sur travaux |
Le moteur doit connaître la mécanique de chaque classe : ce qui se solde, ce qui se reporte, ce qui se régularise.
Chaque étape produit des écritures sur chaque lot. Le moteur doit enchaîner ces étapes sans jamais rompre l'équilibre, pour des dizaines de milliers de copropriétés à la fois.
À la clôture, tous les comptes doivent être équilibrés, sans aucun écart entre débits et crédits. Les charges réelles sont comparées aux provisions appelées, puis l'écart est porté au compte de chaque copropriétaire. Les états comptables destinés à l'assemblée générale sont produits. Et l'exercice suivant repart des soldes de clôture. Ces équilibres et ces mécanismes s'étudient en profondeur ; ils ne s'improvisent pas.
La date de transfert de propriété sépare deux périodes sur le même lot. Provisions et charges se ventilent entre vendeur et acheteur. Le syndic établit l'état daté à partir des comptes du lot. Les sommes du fonds travaux restent attachées au lot vendu. Le compte du vendeur se solde, celui de l'acheteur s'ouvre.
Une comptabilité tenue au lot rend la mutation mécanique. Tenue au copropriétaire, elle devient une opération manuelle, et risquée.
Prenez le décompte individuel de charges : un lot, un exercice, une date d'arrêté. Pour le produire, le moteur croise les tantièmes du lot pour chaque clé, les factures réparties sur toute la durée de l'exercice, les provisions appelées et le fonds travaux, les encaissements imputés au lot, et une éventuelle mutation en cours d'exercice. Quatre exigences s'y ajoutent :
Les données sont sauvegardées, et l'éditeur garantit qu'elles se restaurent. Elles restent hébergées en Europe. Les données personnelles des copropriétaires sont traitées dans le cadre du RGPD. Et l'IA ne traite que ce que le syndic a autorisé : les fournisseurs ne peuvent pas utiliser ces données pour entraîner leurs modèles.
Concevoir les interfaces qui offrent la meilleure interaction et la gestion la plus intuitive, c'est rapprocher à l'écran ce qui est proche dans le métier, donner une logique visuelle que le gestionnaire comprend sans formation longue, réduire les gestes répétitifs, et guider vers la solution du problème posé.
Un écran ne peut afficher que des données qui existent déjà. Or elles naissent dans un ordre strict : le syndic, puis la copropriété, les lots et leurs tantièmes, les copropriétaires, le budget voté, les appels de fonds, les encaissements. Chacune dépend de celles qui la précèdent.
L'écran d'appel de fonds n'a de sens qu'une fois le budget voté et les tantièmes posés. Pourtant, le gestionnaire veut voir sur une même page le budget, l'appel et l'état des paiements. L'écran doit réunir des données nées à des moments différents. Concilier l'ordre de création des données avec la logique visuelle attendue est un travail de conception à part entière.
Choisir les bons langages et technologies pour chaque partie du système, savoir ce qui fonctionne sur le web et sur mobile et à quelles conditions, connaître les mécanismes disponibles avant de concevoir, comprendre comment les choses fonctionnent à l'intérieur. Cette compréhension d'ingénieur est le minimum. Elle ne suffit pas.
Un module conçu sans architecte produit le bon résultat, par un chemin qui n'est pas optimisé. Sur une petite base, la différence passe inaperçue. Sur un milliard de lignes, un détour répété à chaque requête devient des secondes d'attente, puis des minutes, puis un service inutilisable.
L'architecte travaille sur ce qui ne se voit pas : le classement des données (tables et relations organisées pour les accès les plus fréquents), le stockage (chaque donnée là où elle se lit et s'écrit au moindre coût), la structuration des flux (des traitements ordonnés pour ne pas se gêner), les chemins d'accès (index et agrégats conçus pour répondre vite à grande échelle), et la croissance (anticiper le doublement des clients sans tout reconstruire).
Une expérience de pensée : un informaticien excellent, aussi bon qu'on peut l'être, débarque sans savoir que l'IA existe. Il code sans elle. Ce qu'il produit reste infiniment en dessous de ce que produit le même développeur avec l'IA.
Le talent individuel reste indispensable. L'IA s'y ajoute comme une couche de capacités supplémentaires, et c'est la combinaison des deux qui change l'échelle de ce qu'une équipe peut construire.
Six compétences s'empilent, et chacune est nécessaire. Une architecture de données sous-dimensionnée fait céder le moteur dès que le volume arrive. Sans comptabilité profonde, les comptes produits sont faux. Une interface mal pensée rend l'outil pénible au quotidien. Sans ingénieur ni architecte, le système devient lent et coûteux. Et l'équipe qui se prive de l'IA avance infiniment moins vite.
Pour aller plus loin : l'étude illustrée « Le moteur comptable », et la comptabilité de SyndiLibre en vidéo.
Apportez un cas réel : une répartition complexe, une clôture, une vente en cours d'exercice. Nous le rejouons devant vous.