Article sourcé
Questions fréquentes sur le PMS spécialisé MAESTHOM
MAESTHOM est un PMS opérationnel spécialisé dans la location courte durée. Cette FAQ précise son périmètre, iCal, les rôles, les missions et ses limites.
1. Qu’est-ce que l’exploitation d’une location courte durée ?
L’exploitation commence avant la publication et continue après la réservation : vérifier le cadre du logement, tenir une fiche opérationnelle, gérer les canaux et calendriers, qualifier les séjours, préparer arrivées et départs, affecter les missions, traiter les incidents et rendre compte au propriétaire. Une OTA distribue une offre mais n’exécute pas ces opérations locales. Le guide MAESTHOM sépare chaque famille afin que le lecteur puisse agir avec ou sans application. Les règles de droit de louer, de taxe ou de copropriété dépendent du territoire et de la situation ; les sources officielles et leur date doivent être relues avant une décision individuelle.
2. Quel type de logiciel est MAESTHOM ?
MAESTHOM est un PMS opérationnel spécialisé dans la location courte durée. Son périmètre vérifié relie logements, réservations, disponibilités, rotations, missions, prestataires et vues bornées selon le rôle. « PMS » n’a pas un périmètre universel : il faut donc lire la fiche produit et tester le cycle réel. MAESTHOM ne doit pas être présenté comme PMS généraliste complet, ERP, comptabilité, marketplace, OTA ou channel manager complet. Le site explique aussi les méthodes indépendamment du produit et n’attribue aucune capacité à MAESTHOM parce qu’elle serait simplement utile au métier.
3. À quels publics MAESTHOM s’adresse-t-il ?
Le produit vise les gestionnaires et conciergeries qui coordonnent l’exploitation, les propriétaires qui consultent un périmètre utile et les prestataires qui exécutent des missions bornées. Ces profils n’ont ni les mêmes responsabilités ni les mêmes données. Le gestionnaire arbitre les sources, dépendances et exceptions ; le propriétaire décide ou délègue selon son mandat ; le prestataire reçoit logement, créneau, consigne, risque et rapport nécessaires. Une même personne peut cumuler des rôles, mais l’application et la procédure doivent conserver sous quelle autorité elle agit. Le guide des profils détaille RACI, habilitations, entrée et sortie.
4. Faut-il un compte pour utiliser l’application ?
L’application publique canonique est enregistrée comme nécessitant un compte. Les accès gestionnaire et prestataire ont été qualifiés sur la cible publique dans la preuve produit datée ; le site ne généralise pas cette preuve à un rôle ou une fonction non couverts. Les CTA d’inscription ou d’ouverture viennent du registre central et peuvent être retirés si leur destination n’est plus qualifiée. La bibliothèque de guides, elle, reste accessible sans compte et sans installation : elle ne lit aucune réservation, aucun logement et aucun profil. Une démonstration fictive existe séparément pour découvrir l’interface sans utiliser les données d’un compte réel.
5. Que peut faire le gestionnaire ?
Le gestionnaire coordonne les informations connues du logement, du calendrier, de la réservation et des missions. Il peut voir les priorités, qualifier une source, affecter une intervention, contrôler un rapport et préparer un compte rendu selon les capacités validées. Il reste responsable des décisions : un import iCalendar n’est pas une confirmation complète, une mission envoyée n’est pas acceptée, une checklist cochée n’est pas automatiquement une clôture. L’application ne remplace ni le contrat, ni les conditions de plateforme, ni la décision d’une commune, ni le diagnostic d’un professionnel. Le guide du cycle et celui des rotations fournissent les contrôles à appliquer.
6. Que voit le propriétaire ?
Le propriétaire consulte uniquement les logements et synthèses associés à son périmètre et aux droits prévus. Il n’accède pas par défaut aux autres propriétaires, au portefeuille complet du gestionnaire, aux conversations internes ou aux données détaillées du prestataire. Le compte rendu doit afficher période, sources, définitions des indicateurs, faits, interventions, incidents et décisions attendues. Une vue propriétaire ne transforme pas une observation en rendement garanti et ne remplace pas le mandat. Lors d’une fin de relation, export, restitution documentaire, réservations existantes et révocation des accès doivent être préparés au lieu de laisser un compte ouvert indéfiniment.
7. Que voit le prestataire ?
Le prestataire reçoit le logement concerné, le créneau, les accès autorisés, la checklist, les risques, le résultat attendu et le canal de signalement nécessaires à sa mission. Il ne voit pas par défaut les revenus, propriétaires, autres logements, moyens de paiement ou dossier complet du voyageur. L’accès est limité dans le temps et révoqué lorsque la mission ou la relation se termine. Le prestataire signale une anomalie et remet un rapport ; il ne décide pas seul d’une indemnisation, d’un changement de logement ou d’une conformité globale. La CNIL recommande de minimiser les données et de cadrer les habilitations et la sous-traitance.
8. MAESTHOM est-il un ERP ou un outil comptable ?
Non. MAESTHOM relie un périmètre de location courte durée à ses opérations terrain. Un ERP couvre des fonctions de gestion plus larges ; un outil comptable tient des écritures et pièces selon son cadre ; un prestataire de paiement exécute des transactions. Le produit peut organiser des montants ou indicateurs connus sans devenir l’un de ces systèmes. Revenu brut, net bancaire, marge, fiscalité et taxe de séjour sont des notions distinctes. Le site n’invente pas de prix, de tarif local, de conseil fiscal ou de capacité de paiement. Toute future interopérabilité attend une passation produit qualifiée.
9. MAESTHOM est-il un channel manager ?
Non. Un channel manager coordonne plusieurs canaux selon ses connecteurs et son offre : disponibilités, tarifs, restrictions ou réservations peuvent être couverts de façon variable. MAESTHOM est un PMS opérationnel spécialisé ; il peut consommer des calendriers iCalendar et organiser la suite métier, mais ne revendique pas une synchronisation multi-plateformes complète. Citer Airbnb, Booking.com, Abritel/Vrbo ou Leboncoin dans un guide ne prouve aucune intégration officielle. Pour comparer, vérifiez canaux, champs, fréquence, erreurs, reprise, coûts, export et mode dégradé sur un scénario identique.
10. Que transporte un flux iCalendar ou ICS ?
Le standard iCalendar défini par la RFC 5545 transporte des événements avec identifiant, début, fin et propriétés variables. En location courte durée, un flux partage surtout des périodes occupées ou indisponibles. Il ne garantit ni identité complète, paiement, statut contractuel, nombre d’occupants, messagerie, heure d’arrivée ou mission de ménage. MAESTHOM doit d’abord conserver l’événement et sa source, puis le qualifier selon les informations réellement disponibles. L’URL ICS peut donner accès à des périodes et doit rester secrète : jamais dans le HTML public, une capture, une URL analytique ou une mission terrain.
11. La synchronisation iCalendar est-elle en temps réel ?
Non. Un flux est relu périodiquement selon le producteur et le consommateur. Une modification peut arriver après une action terrain ou rester invisible pendant une panne. L’exploitation doit afficher dernière tentative, dernier succès, fraîcheur, nombre d’événements et erreur, puis bloquer les réouvertures risquées lorsque la source est en retard. La recette mesure création, modification, suppression, doublon et reprise ; elle ne transforme pas un délai observé en garantie universelle. Un seul poller logique traite une même source avec checkpoint, idempotence, retry borné et publication atomique.
12. Que se passe-t-il si une source calendrier est inaccessible ?
Le dernier état connu reste identifié avec sa fraîcheur ; il n’est pas présenté comme actuel. Les dates critiques ne sont pas rouvertes automatiquement. Le gestionnaire vérifie les canaux autorisés, protège les arrivées proches et attribue une action de reprise. À la reconnexion, les événements sont rapprochés par source et identifiant ; un conflit passe en arbitrage plutôt qu’en fusion automatique. Les URL et contenus réels restent dans une configuration privée. Le guide iCalendar décrit le mode dégradé, les seuils et le rollback sans promettre l’absence de doubles réservations.
13. Comment traiter une modification ou une annulation ?
Une demande, une décision, un statut effectif dans le canal, un remboursement, une date libérée et une mission annulée sont des événements séparés. Le gestionnaire vérifie l’autorité, conserve avant/après, auteur, source et heure, puis recalcule calendrier, accès, messages, rotation et missions. Une annulation ne supprime pas une mission déjà exécutée ; un remboursement ne prouve pas que le logement est rouvert. Les conditions varient selon contrat et canal. Le site fournit une méthode et des sources, pas une décision de remboursement ou une interprétation juridique individuelle.
14. Qu’est-ce qu’une rotation entre deux séjours ?
La rotation va du départ réel jusqu’à la décision que le logement est prêt, bloqué ou prêt sous réserve. Elle comprend accès, remise en état, linge, consommables, contrôle, anomalies et fermeture. La fenêtre utile se calcule entre départ et arrivée en retirant contrôle et marge ; elle est comparée à la durée propre au logement. Une rotation ne doit pas réduire silencieusement les critères lorsque le temps manque. Le guide public détaille hiérarchie des sources, rôles, sécurité, checklist, arbre d’exception, cas complet et preuve proportionnée, utilisables avec MAESTHOM ou un autre outil.
15. La checklist clôture-t-elle une mission ?
Non. La checklist décrit les critères à parcourir ; elle n’établit pas automatiquement qui a exécuté, quand, avec quels écarts et quelle décision a suivi. Lorsque le rapport est requis, il porte heure de fin, observations et anomalies nécessaires au gestionnaire. Une série de photographies ne remplace pas le contrôle : chaque image doit répondre à un besoin et éviter personnes, documents ou objets privés inutiles. La mission est clôturée selon les critères et responsabilités définis. Un statut automatique lié à l’heure ou au dernier clic ne suffit pas.
16. Comment MAESTHOM protège-t-il les données par rôle ?
La vérité produit prévoit des vues bornées par rôle ; la méthode éditoriale applique finalité, minimisation, habilitation, durée et révocation. Le site ne prétend pas certifier toute l’architecture de l’application à partir de cette seule règle. Une preuve fraîche doit couvrir le profil et la cible publique. Les données de réservation, adresses, codes, URL ICS et informations de séjour ne sont jamais nécessaires au site-guide et ne doivent pas apparaître dans ses URL, journaux ou analytics. Pour un incident ou une photo, collectez seulement l’élément lié au fait à établir.
17. Le site-guide reçoit-il les réservations ou les adresses ?
Non. maesthom.com est un site éditorial statique : il explique le domaine, les méthodes, comparatifs et limites. Il ne lit pas la base métier, ne reçoit ni réservation, ni adresse, ni code d’accès, ni URL iCalendar, ni identité voyageur. Les CTA quittent le guide vers une destination publique enregistrée. Une URL de site ne doit contenir que des paramètres publics et nécessaires ; aucune donnée métier privée n’est transmise. Les pages de contact n’activent pas de formulaire tant qu’un canal public factuel n’est pas fourni.
18. MAESTHOM décide-t-il si un logement peut être loué ?
Non. Le droit de louer dépend du logement, de son usage, de la commune, de la copropriété et des règles en vigueur. Les démarches peuvent inclure déclaration, enregistrement ou changement d’usage selon le territoire. La Direction générale des Entreprises documente l’évolution du téléservice national, mais l’autorité et la disponibilité doivent être vérifiées à la date du dossier. MAESTHOM peut aider à conserver une échéance ou une pièce ; il ne délivre pas d’autorisation, ne qualifie pas juridiquement la situation et ne remplace pas un interlocuteur compétent.
19. MAESTHOM calcule-t-il la taxe de séjour ou l’impôt ?
Le site explique que la taxe de séjour est locale et que les obligations fiscales dépendent de la situation, mais il ne fournit pas un montant garanti. Le tarif peut varier selon commune, période, classement et mode de collecte. Une plateforme peut collecter certains montants selon le dossier, sans rendre la règle identique partout. MAESTHOM ne doit pas être présenté comme moteur fiscal ou comptabilité complète sans preuve. Les pages concernées affichent sources, territoire et date, puis orientent vers Service Public, impots.gouv.fr ou l’autorité locale.
20. Comment comparer MAESTHOM avec un tableur ou un autre PMS ?
Utilisez le même scénario et les mêmes critères : couverture du cycle, autorité de donnée, fraîcheur, droits, gestion des erreurs, mode dégradé, export, support et coût total. Le tableur est souple et accessible mais demande contrôles, habilitations et dédoublonnage. Un PMS généraliste peut couvrir davantage de fonctions avec plus de paramétrage. Un outil spécialisé peut mieux relier réservation et terrain mais laisser comptabilité ou distribution à d’autres solutions. MAESTHOM est évalué avec les mêmes critères ; une fonction future ou non testée vaut zéro jusqu’à preuve.
21. Existe-t-il une démonstration publique ?
Oui. Le registre central qualifie une démonstration MAESTHOM publique à données fictives, distincte de l’application canonique. Elle sert à comprendre l’interface sans utiliser les données d’un client ou d’un compte de production. Elle ne prouve pas un usage réel, un connecteur OTA, une notification externe ou une persistance au-delà de son contrat public. Le site emploie le libellé explicite « Démo MAESTHOM — données fictives » et ne présente pas cette URL comme la production. Toute évolution de destination doit être mise à jour dans le registre avant le CTA.
22. Les captures du site viennent-elles de la production ?
Non. Les captures utilisées sont des visuels de démonstration à données fictives et portent une légende et une limite. Elles ne montrent aucun client, logement, voyageur ou prestataire réel. Une capture de calendrier illustre la lecture d’une fenêtre ; une mission fictive illustre le périmètre du prestataire ; elles ne prouvent ni stockage photo complet, ni synchronisation OTA, ni résultat métier. Le site n’invente pas de témoignage, d’usage ou de volume. Un visuel obsolète doit être retiré ou remplacé par un actif validé, sans retoucher un logo hors passation Identité.
23. LOGIMMO et MAESTHOM sont-ils deux produits ?
Non. MAESTHOM remplace LOGIMMO comme nom public du même produit de conciergerie et de location courte durée, avec continuité de l’historique fonctionnel, des données et des droits selon la décision canonique. LOGIMMO ne doit plus être présenté comme produit actif distinct. Les anciennes URL et versions techniques restent conservées pour rollback et continuité, mais le contenu canonique public pointe vers MAESTHOM afin d’éviter deux copies indexables. Cette migration de nom ne prouve pas une nouvelle fonction et ne modifie pas le périmètre du produit.
24. Comment signaler une erreur ou une source périmée ?
Utilisez la page Corrections du site en indiquant l’URL, le passage et une source publique vérifiable. Ne transmettez aucune réservation, adresse, document privé, secret, code ou identité voyageur. L’équipe relit la source primaire ou de référence, la vérité produit et les pages transverses qui utilisent le même fait. Une affirmation devenue invérifiable est retirée ou qualifiée ; elle n’est pas masquée par une reformulation marketing. La date de révision et, si nécessaire, la politique d’indexation sont mises à jour. Aucun canal de contact nominatif n’est inventé tant que les mentions factuelles ne sont pas disponibles.
Sources
- · MAESTHOM · vérifié le 2026-07-26
- · DGCCRF · vérifié le 2026-07-22
- · DGCCRF · vérifié le 2026-07-23
- · Direction générale des Entreprises · vérifié le 2026-09-24
- · RFC Editor · vérifié le 2026-07-22
- · CNIL · vérifié le 2026-07-23
- · CNIL · vérifié le 2026-07-23
- · CNIL · vérifié le 2026-07-23
- · Service Public · vérifié le 2026-07-22
- · Service Public · vérifié le 2026-07-22