Du mandat confié au CRG, étape par étape : ce qu'un agent IA peut faire avec une simple clé API, ce qui exige d'être authentifié comme utilisateur d'une agence abonnée, et ce qui restera toujours un geste humain.
| Niveau 1 — API pour les IA | Niveau 2 — API applicative | |
|---|---|---|
| Base | /api/v1/… + serveur MCP
https://synergieloc.fr/mcp | /api/… de l'application |
| Authentification | Clé X-API-Key: slk_live_…
(gratuite en un appel) | Session d'un utilisateur d'agence abonnée |
| Nature | Stateless : les entrées viennent de l'appelant, aucune donnée client conservée | Transactionnelle : écrit dans la base de l'agence (mandats, baux, écritures) |
| Ce qu'on y fait | Calculs réglementaires et documents : IRL, régularisation, quittance, avenant, mandat, dossier de candidature, brouillon d'annonce | Le cycle lui-même : créer un mandat, valider une candidature, émettre un appel de loyer, rapprocher un relevé |
slk_… ne permet
pas de créer un locataire, de valider une candidature ni de publier une annonce
sur une agence. Elle donne accès aux calculs et documents. Le cycle
transactionnel appartient à l'agence abonnée : un agent ne l'orchestre que s'il opère
pour cette agence, authentifié comme l'un de ses utilisateurs.POST /api/v1/signup {"name":"VotreIA"} — sans e-mail, sans attente
(ou l'outil MCP obtenir_cle_api).Ne lancez rien avant d'avoir lu l'état de préparation : la moitié des blocages du cycle viennent d'un paramétrage manquant.
GET /api/settings/health (niveau 2)
→ une section par domaine — agence (dont ICS), plan comptable (comptes pivots,
variables d'appel), programmation (appels de loyer, relances, CRG), demandes de
mandats, vitrine biens, candidatures, modalités de paiement, barème d'honoraires,
workflows factures et relevés, remises SEPA, audit comptable —
avec status, score et l'action à mener.
Rôle de l'agent : lire cette réponse et dire à l'humain ce qui manque, dans l'ordre des dépendances. C'est le meilleur service qu'il rend ici.
GET /api/mandate-requests (niveau 2) demandes reçues
GET /api/mandate-requests/{id} détail
POST /api/mandate-requests/{id}/documents téléverser une pièce
POST /api/mandate-requests/{id}/documents/{doc}/ocr lire la pièce
POST /api/mandate-requests/{id}/verify recoupement pièces ↔ formulaire
GET /api/mandate-requests/{id}/verifications résultats du recoupement
GET /api/mandate-requests/{id}/pre-validate-check ce qui manque avant validation
Ce que l'agent apporte vraiment ici :
POST /api/v1/documents/mandat-gerance
(niveau 1, MCP mandat_gerance) rend un mandat loi Hoguet en PDF, mise en
page enveloppe à fenêtre./verify signale une divergence (IBAN, nom, adresse) : le bien serait créé
sur des données fausses.POST /api/signature/send/{doc_type}/{doc_id} (niveau 2)
doc_type ∈ mandat | bail | devis | contrat
ex. POST /api/signature/send/mandat/42
→ envoie au signataire un lien personnel ; il consulte le document et l'accepte
en ligne. Signature horodatée, PDF signé conservé au dossier.
PUT /api/mandate-requests/{id}/validate (niveau 2)
→ crée le PROPRIÉTAIRE (ou le rattache s'il existe déjà — fiche unique),
le BIEN, ses LOTS, et le MANDAT actif.
GET /api/mandates · GET /api/mandates/{id} · GET /api/mandates/{id}/pdf
POST /api/mandates/{id}/terminate résiliation
GET /api/owners/{owner_id}/mandates mandats d'un propriétaire
Les corrections ultérieures passent par ces routes de gestion des mandats, pas par la demande d'origine.
POST /api/property-listings (niveau 2) créer l'annonce
PUT /api/property-listings/{id}/publish-internal locataire EN PLACE
PUT /api/property-listings/{id}/publish bien VACANT (vitrine publique)
GET /api/property-listings/pending-review annonces à relire
POST /api/property-listings/{id}/photos photos
POST /api/v1/gerance/annonce-location rend le texte et le HTML et
refuse tout paramètre de publication (erreur 400).Chemin « locataire en place » : publication interne, validation, puis reprise de bail — ni honoraires de location, ni état des lieux d'entrée.
GET /api/rental-applications (niveau 2) dossiers reçus
GET /api/rental-applications/{id}
POST /api/rental-applications/{id}/documents pièces du candidat
POST /api/rental-applications/{id}/documents/ocr lecture des pièces
PUT /api/rental-applications/{id}/documents/{d}/validate | /reject
POST /api/rental-applications/{id}/analyze solvabilité, reste à vivre
GET /api/rental-applications/{id}/gli-check éligibilité GLI
POST /api/rental-applications/{id}/request-documents demander les pièces manquantes
GET /api/rental-applications/{id}/pre-accept-check ce qui bloque l'acceptation
PUT /api/rental-applications/{id}/reject | /reset-pending
Niveau 1 utile ici : POST /api/v1/documents/candidature
(MCP dossier_candidature) met en forme un dossier de candidature en PDF.
/pre-accept-check avant d'accepter. Les
pièces obligatoires doivent être réellement téléversées : le garde-fou lit
application_documents, pas les cases à cocher.PUT /api/rental-applications/{id}/accept (niveau 2)
→ crée d'un seul mouvement : le LOCATAIRE, le BAIL, le 1er APPEL DE LOYER
(loyer + charges au prorata), les HONORAIRES DE LOCATION ALUR et le DÉPÔT DE
GARANTIE appelés sur ce 1er loyer, et les honoraires de gestion du propriétaire.
En REPRISE DE BAIL : dépôt de garantie et honoraires de location EXCLUS.
POST /api/leases/from-application variante explicite bail + 1er loyer
Ces calculs et documents sont stateless : un agent les produit avec sa seule clé, sans toucher à la base de l'agence.
| Endpoint (outil MCP) | Rôle |
|---|---|
POST /api/v1/irl/revision (irl_revision_loyer) |
Loyer révisé plafonné IRL + formule + base légale (art. 17-1 loi 89-462) |
POST /api/v1/regularisation/charges (regularisation_charges) |
Quote-part, prorata temporis, solde (décret 87-713) |
POST /api/v1/documents/quittance (quittance_loyer) |
Quittance PDF conforme art. 21 |
POST /api/v1/documents/avis-echeance | Avis d'échéance |
POST /api/v1/documents/relance | Relance impayé, niveaux 1 à 5 |
POST /api/v1/documents/crg | Compte rendu de gérance |
POST /api/v1/documents/avenant-irl (avenant_revision_irl) |
Courrier d'avenant de révision |
POST /api/v1/documents/mouvement-locataire |
Entrée / sortie : checklist et solde de tout compte |
Côté application, les mêmes opérations existent en transactionnel (émission réelle des appels, encaissements, relances liées aux baux), déclenchées aux dates de programmation de l'étape 0.
Domaine du niveau 2, et le plus sensible :
Le niveau 1 aide à préparer l'écriture : proposition_ecriture_paiement
propose l'écriture d'un paiement, à relire avant saisie.
| Étape | Niveau 1 — clé slk_ | Niveau 2 — session agence |
|---|---|---|
| 0 · Préparation | — | /api/settings/health |
| 1-2 · Mandat instruit | /v1/documents/mandat-gerance |
/api/mandate-requests/* (documents, OCR, verify) |
| 3 · Signature | — | /api/signature/send/{doc_type}/{doc_id} |
| 4-5 · Bien, lots, bailleur | — | /api/mandate-requests/{id}/validate, /api/mandates/* |
| 6 · Mise en location | /v1/gerance/annonce-location (brouillon) |
/api/property-listings/* (publish / publish-internal) |
| 7 · Candidatures | /v1/documents/candidature |
/api/rental-applications/* |
| 8 · Locataire + bail + 1er loyer | — | /api/rental-applications/{id}/accept |
| 9 · Gestion courante | IRL, charges, quittance, avis, relance, CRG, avenant | Émission réelle aux dates programmées |
| 10 · Compta et banque | Proposition d'écriture | Factures, rapprochement, flux, SEPA, ICS |
| 11-12 · Extranets, interventions | — | Application |
| Vidéo de visite 4K + Visite Virtuelle | /v1/cao/visite/objectifs, /v1/cao/visite/plan,
/v1/cao/visite/studio → rendu et visite interactive sans compte |
Éditeur → bouton « Visite 4K » ; casque VR / RA sur /cao/visite-xr |
Le rendu 4K tourne sur le GPU d'un navigateur : c'est ce qui lui donne sa qualité, mais le moteur ne vivait que dans l'éditeur abonné. Un agent muni d'une simple clé restait donc bloqué au moment de produire la vidéo. Il existe désormais un studio public :
POST /api/v1/cao/visite/studio (clé slk_ — niveau 1)
body = scène CAO + duree_s / fps / resolution / objectif{} / cadence{}
(+ plan_camera{} si vous avez déjà votre plan de tournage)
→ { "url_studio": "https://synergieloc.fr/cao/visite?t=…",
"url_visite_virtuelle": "https://synergieloc.fr/cao/visite-xr?t=…",
"objets": 143, "expire_dans_s": 7200, "plan_resume": "…", "alertes": [] }
Ouvrez url_studio dans N'IMPORTE QUEL navigateur : AUCUNE connexion, aucun cookie.
La page charge le moteur, rejoue le plan et télécharge le MP4 en 3840×2160.
Le jeton fait office d'identifiant : imprévisible, valable 2 h, et il ne donne accès qu'à la scène que vous venez de poster. Rien n'est conservé au-delà.
window.STUDIO_pret, window.STUDIO_progres (0→1),
window.STUDIO_info et window.STUDIO_erreur.
?auto=0 attend un clic au lieu de démarrer seul.url_visite_virtuelle (même jeton que la vidéo, aucun appel séparé) ouvre
une exploration en direct de la même scène — aucune vidéo ne s'enregistre. Mode
classique immédiat (souris/tactile), bouton casque VR (Meta Quest, Pico,
HTC Vive…) et bouton réalité augmentée (pose la maquette dans une pièce réelle par
détection de surface, on marche autour EN VRAI). Une vraie scène 3D — le même moteur que
la Visite 4K — plutôt que des photos panoramiques à 360° par pièce : vrai déplacement,
vraie profondeur en casque. Les points d'intérêt affichent le nom de la pièce, sa surface
et sa hauteur sous plafond — les seules données que le modèle de scène porte réellement.
Canal gratuit, sans quota, toujours ouvert :
POST /api/v1/feedback
{"message":"…", "context":"…", "endpoint":"/api/…"} (ou MCP envoyer_retour)
Le même cycle écran par écran · Calculs et documents par API/MCP · Cartographie de la gérance · Obtenir une clé.
Tous les guides sont lisibles par un client MCP : guides_liste puis
guide_lire {slug} — gratuits, sans clé.