L'utilisateur voit des écrans : des soldes, des appels de fonds, des relevés. Le poids réel se trouve dessous, dans le moteur comptable. C'est lui qui concentre la technicité du métier, et lui qui décide si le logiciel tient face aux gros syndics.
Un moteur comptable de syndic se conçoit d'emblée pour quelque chose de massif. Voici pourquoi, chiffres à l'appui.
Un logiciel pensé pour une copropriété de 10 lots fonctionne en démonstration. Il cède dès que la charge réelle arrive. La réalité du terrain, ce sont des centaines de syndics, chacun avec des dizaines de copropriétés, sur une seule plateforme.
La conséquence est commerciale. Le modèle d'un éditeur repose sur la multiplication des clients. Un moteur qui ne tient pas la charge interdit la croissance : chaque nouveau syndic aggrave le problème.
Chaque niveau multiplie le précédent. La volumétrie finale est le produit de toute la chaîne.
Aux heures creuses, une route large paraît surdimensionnée. À l'heure de pointe, seule celle qui a été dimensionnée pour le pic reste praticable. Un logiciel de syndic obéit à la même règle.
On raisonne sur lui, jamais sur la moyenne.
On prévoit le plus gros syndic et la plus grosse copropriété du marché.
On teste la plateforme sous la charge la plus forte qu'on puisse rencontrer.
On garde de la place pour la croissance des clients.
Les appels trimestriels tombent aux mêmes dates pour la quasi-totalité des copropriétés. Toute la plateforme encaisse le choc au même moment, quatre fois par an.
Les clôtures et les assemblées générales ajoutent une seconde vague de traitements lourds, à d'autres dates.
La capacité pour laquelle SyndiLibre est dimensionné.
La plus grosse copropriété gérée aujourd'hui dans SyndiLibre.
La capacité recommandée, au-delà de la fourchette courante de 5 à 100.
L'ordre de grandeur retenu pour le calcul : des centaines de syndics chez un même éditeur.
Le dimensionnement dépasse largement la plus grosse copropriété réellement gérée. La marge fait partie de la conception.
Le lot est l'unité de base de la gestion comptable, quel que soit le nombre de lots que détient un copropriétaire. Tout ce qui suit en découle.
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, la répartition se fait au moment de la saisie : chaque facture enregistrée est aussitôt ventilée sur les lots.
Chaque dépense suit sa clé de répartition (charges générales, bâtiment, ascenseur…) et se calcule lot par lot, selon les tantièmes.
Des hypothèses moyennes, un comptage minimal sans métadonnées ni gestion accessoire. La réalité des gros syndics dépasse ces chiffres.
| Hypothèse | Valeur |
|---|---|
| Syndics sur la plateforme | 500 |
| Copropriétés par syndic | 50 |
| Lots par copropriété | 30 |
| Lots gérés | 750 000 |
| Lignes par opération (2 d'écriture, 2 de gestion) | 4 au minimum |
| 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.
Un écran qui calcule fait attendre le gestionnaire ; une réponse immédiate le laisse produire. La productivité exige que tout réponde vite, avec une architecture de données taillée pour le volume.
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.
Chaque type de donnée est confié au moteur conçu pour lui.
Infrastructure AWS · calcul et conteneurs, stockage et sauvegardes, CDN et pare-feu, observabilité, secrets et accès, livraison continue.
Chaque syndic accède à ses seules données, sur une plateforme commune.
Données découpées par syndic, copropriété et exercice, pour ne lire que le nécessaire.
Les soldes par lot sont maintenus au fil de l'eau plutôt que recalculés depuis l'origine.
Une écriture validée ne se modifie plus : on la contre-passe. La traçabilité reste totale.
Les appels de fonds de milliers de copropriétés sont générés en parallèle, en arrière-plan.
Chaque écriture est équilibrée en débit et crédit dès son enregistrement, sans exception.
Au-delà de ce qu'en voit l'utilisateur : les écritures, les comptes, les équilibres et les moments où tout doit tomber juste.
La comptabilité est une chorégraphie. Celui qui ne connaît que ce que voit le spectateur ne peut pas la concevoir.
Le gestionnaire. Il voit la danse : soldes, appels, relevés, comptes d'assemblée générale.
Les écritures et les comptes. Chacun doit être au bon endroit au bon moment.
L'éditeur. Il conçoit tout ce qui doit se passer pour que le spectateur voie la bonne danse.
Un débit et un crédit de même montant. La somme des débits égale toujours la somme des crédits.
| 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 |
Schéma simplifié, sur la base du plan comptable des copropriétés. Chaque écriture sur le compte 450 se démultiplie au niveau du lot.
Il est 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.
Le moteur doit connaître la mécanique de chaque classe : ce qui se solde, ce qui se reporte, ce qui se régularise.
| 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 |
Chaque étape produit des écritures sur chaque lot. Le moteur les enchaîne sans jamais rompre l'équilibre, pour des dizaines de milliers de copropriétés à la fois.
La date de transfert de propriété sépare deux périodes sur le même lot.
Tenue au lot, la mutation devient mécanique. Tenue au copropriétaire, elle reste une opération manuelle et risquée.
Chaque édition se calcule par lot, par copropriété et par exercice, puis se produit pour toutes les copropriétés du syndic.
Un lot, un exercice, une date d'arrêté. Pour le produire, le moteur réunit tout ce qui s'est passé sur ce lot.
Clôture, période ou date de vente : tout est arrêté à une date précise.
La somme des décomptes de tous les lots égale les charges présentées en assemblée générale.
Les annexes comptables suivent un format fixé, le même pour toutes les copropriétés.
Les éditions sortent pour toutes les copropriétés aux mêmes dates, au moment du pic.
Les interfaces, l'ingénierie et l'architecture logicielle. Chacun repose sur le précédent.
Le but : les interfaces qui offrent la meilleure interaction et la gestion la plus intuitive.
Les éléments proches dans le métier se retrouvent proches à l'écran.
Le gestionnaire comprend l'écran sans formation longue.
Les tâches quotidiennes se font en un minimum d'actions.
L'interface guide vers la solution du problème posé.
Chaque donnée dépend de celles qui la précèdent. Le concepteur doit concilier cet ordre de création avec la logique visuelle qu'attend l'utilisateur.
Exemple. 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.
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.
Organiser les tables et leurs relations pour les accès les plus fréquents.
Placer chaque donnée là où elle se lit et s'écrit au moindre coût.
Ordonner les traitements pour qu'ils ne se gênent pas.
Index et agrégats conçus pour répondre vite à grande échelle.
Anticiper le doublement des clients sans tout reconstruire.
Le même excellent professionnel, avec ou sans IA, ne joue pas dans la même catégorie.
Il est aussi bon qu'on peut l'être, et 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.
Des apports concrets, pour l'équipe qui construit et pour le syndic qui s'en sert.
Générer du code, des tests et de la documentation en une fraction du temps.
Comparer des options d'architecture avant d'en retenir une.
Détecter des anomalies et des incohérences dans les règles et les données.
Lecture automatique des factures, aide à la saisie, réponses aux questions.
Un moteur conçu pour le pic, tenu au lot, construit par une équipe qui réunit comptabilité, architecture, ingénierie, ergonomie et IA. Venez le voir tourner.