Guides
Le travail est-il terminé ? Distinguer devis, intervention, facture et règlement
Suivre un travail du devis à la seconde visite : distinguer dans PropertyOS ce qui était prévu, ce qui a été fait, les documents et le règlement vérifié.
Eternity Labs ·Pour savoir où en est un travail dans le logement, je distinguerais ce qui a été proposé, ce qui était prévu au calendrier, ce qui a réellement eu lieu et ce que j’ai vérifié comme réglé. Un devis, un rendez-vous, une note d’intervention et une facture peuvent concerner le même chantier sans décrire la même étape. PropertyOS permet d’organiser ces éléments liés ; leur utilité dépend aussi du sens que je préserve en les enregistrant.
Prenons un exemple fictif. Deux portes d’un placard de l’entrée ont besoin d’être ajustées. Un artisan propose une intervention, décale sa première venue, règle une porte puis commande une pièce pour l’autre. Une facture arrive avant son retour. Cette histoire n’est ni un témoignage client ni un essai de PropertyOS. Elle sert à montrer comment je garderais un petit travail compréhensible.
Je ne cherche pas à construire une seconde comptabilité. Je veux répondre à une question plus simple : qu’est-ce qui a réellement changé dans l’entrée, et qu’est-ce qui attend encore ? La réponse devient plus claire quand le dernier document reçu ne remplace pas toute l’histoire précédente.
Le travail a besoin d’une identité avant d’accumuler les pièces
« Réparation du placard » semble précis jusqu’au moment où plusieurs pièces possèdent des placards et où deux artisans sont passés la même année. Je commencerais par le lieu, l’équipement concerné et le problème que j’ai demandé d’examiner. Ici : le placard de l’entrée, ses deux portes et un réglage qui pourrait demander une pièce.
PropertyOS présente les biens, pièces, équipements, documents, artisans, travaux, interventions, dépenses, garanties et entretiens comme les éléments d’une chronologie liée. Ces notions conviennent à notre exemple. J’utiliserais les fiches et les associations pertinentes proposées dans l’application installée, sans supposer un circuit automatique ou un changement de statut invisible. Présentation officielle de PropertyOS.
Une photographie de référence pourrait montrer de quel placard il s’agit. Je ne lui ferais pas dire que le travail est terminé : son premier rôle serait l’identification. D’autres images pourront ensuite documenter un changement, avec leur date et leur contexte clairement distingués.
Je donnerais aussi une identité reconnaissable à l’artisan. Un prénom retenu pendant un appel ne suffit pas toujours à relier la visite aux documents quelques mois plus tard. Le dossier doit rester lisible sans m’obliger à reconstituer tous les échanges de mémoire.
Première question : que souhaitait-on faire ?
Dans notre cas fictif, la première proposition concerne le réglage des deux portes. Lors de sa venue, l’artisan constate qu’une pièce est nécessaire pour l’une d’elles. Je conserverais la proposition initiale et cette information ultérieure comme deux étapes d’un même travail.
Dans mes notes, je pourrais écrire : « Demande initiale : régler les deux portes du placard de l’entrée. Après la visite : une porte réglée, une pièce nécessaire pour l’autre. » La formulation explique ce qui a changé. Elle ne transforme pas la réparation envisagée de la seconde porte en intervention déjà réalisée.
Si un document révisé arrive, je l’identifierais comme tel et préciserais ce qu’il modifie. Je ne remplacerais pas silencieusement le premier fichier au risque de ne plus comprendre l’écart. À l’inverse, deux versions d’une proposition ne deviennent pas deux chantiers indépendants simplement parce qu’elles occupent deux lignes.
Il s’agit d’une méthode de classement, pas d’une interprétation de la portée juridique d’un devis. Si la question réelle concerne ce qui a été convenu avec l’artisan, les documents concernés et ses explications comptent. PropertyOS me servirait à organiser ces informations, sans décider à la place des personnes ce qu’elles ont accepté.
Deuxième question : le rendez-vous a-t-il eu lieu ?
Dans l’exemple, la venue prévue mardi est reportée au jeudi. Je garderais le mardi identifiable comme une ancienne prévision. Sinon, quelques mois plus tard, je pourrais croire que deux visites ont eu lieu alors qu’il n’y en a eu qu’une.
Le rendez-vous et l’intervention méritent des descriptions différentes. Le premier indique quand une personne était attendue. La seconde décrit ce que je sais de sa venue réelle. J’enregistrerais la date effective une fois l’événement passé, puis rattacherais les pièces utiles à cet événement.
Si je ne suis plus certain de la date, je l’indiquerais. « Date de visite à confirmer ; facture reçue vendredi » me serait plus utile qu’un vendredi recopié partout parce qu’il s’agit de la seule date bien visible. L’incertitude devient alors une petite question précise à résoudre.
Je ne supposerais pas que PropertyOS réserve la venue, envoie un rappel, confirme l’arrivée ou détecte une absence. Ces fonctions ne sont pas établies par la description publique utilisée ici. La chronologie devient utile parce que j’y apporte des événements vérifiés, pas parce que la mise en situation imagine un service de réservation.
Troisième question : qu’a changé cette visite ?
« L’artisan est passé » peut être exact et pourtant insuffisant. Dans notre entrée, une porte a été réglée tandis que l’autre attend une pièce. Je noterais les deux résultats dans un langage ordinaire, en gardant claire l’origine de chaque affirmation.
Par exemple : « La porte de gauche a été réglée pendant la visite. L’artisan indique qu’une charnière doit être remplacée à droite. » La première phrase décrit un événement. La seconde attribue une recommandation. Aucune n’exige de prétendre que j’ai moi-même confirmé le diagnostic technique.
Une photographie peut documenter l’aspect après la venue. Une note peut conserver l’explication donnée. Une référence fournisseur peut identifier la pièce évoquée. Ces éléments apportent des informations différentes. Je les relierais au même travail sans leur appliquer indistinctement un libellé vague comme « terminé ».
Si le sujet demandait une évaluation professionnelle particulière, un dossier bien classé ne la remplacerait pas. Même pour ce placard simple, mon rôle consiste à distinguer ce que j’ai constaté de ce qui m’a été expliqué. La clôture de ma fiche ne deviendrait pas un certificat de bonne exécution.
Quatrième question : à quoi correspond ce montant ?
À l’arrivée de la facture, je chercherais d’abord ce qu’elle couvre. La description concerne-t-elle la première visite, la pièce commandée ou le travail complet ? Si je ne le comprends pas, l’étape utile est une question précise à l’artisan.
Dans mon dossier personnel, je distinguerais un montant proposé, un montant facturé et un paiement que j’ai effectivement vérifié. Ce sont des descriptions des éléments en ma possession. Les additionner sans regarder leur rôle pourrait me faire compter plusieurs fois le même travail.
Imaginons une proposition initiale, sa révision, une facture et une confirmation de paiement. Quatre fichiers ne représentent pas nécessairement quatre dépenses. Je déterminerais le rôle de chacun avant de reprendre leurs chiffres dans mon suivi personnel. Je ne décris ici ni rapprochement bancaire automatique ni fonction comptable supposée de PropertyOS.
Je ne considérerais pas non plus le travail physique comme terminé parce qu’un règlement a été effectué. Dans notre histoire, la seconde porte attend encore. Un paiement et une tâche inachevée peuvent coexister. À l’inverse, une visite terminée ne prouve pas que sa facture est réglée. Mon dossier doit permettre de conserver ces questions distinctes.
Un tableau court rend la succession lisible
Je préparerais une synthèse de ce genre dans mes propres notes de suivi. Les mots employés ci-dessous sont des repères rédactionnels, pas les noms de champs ou de statuts automatiques promis par PropertyOS.
| Élément du dossier fictif | Ce qu’il m’apprend | Ce qu’il ne démontre pas |
|---|---|---|
| Première proposition | Le travail initialement décrit | Que le travail a eu lieu |
| Rendez-vous reporté | La nouvelle date envisagée | Que l’artisan est venu |
| Note de première intervention | Une porte réglée, une autre en attente | Que l’ensemble est terminé |
| Facture | Le montant et la prestation qui y figurent | À elle seule, mon paiement ou la seconde visite |
| Confirmation de paiement | Un règlement que je peux identifier | L’achèvement de toutes les tâches physiques |
| Note de retour | Les faits rapportés ou constatés à cette date | Une garantie ou un contrôle non documenté |
Ce tableau pourrait m’aider avant un appel. Au lieu de demander vaguement où en est le placard, je pourrais demander si la pièce est arrivée et si une date de retour est possible. La question découle directement du point laissé ouvert.
Je garderais cette synthèse assez courte pour être relue. Les pièces d’origine resteraient utiles pour examiner un détail. Une note qui répète chaque phrase de chaque document devient un autre endroit où chercher, plutôt qu’une aide à la prochaine décision.
Cinquième question : que faut-il pour terminer le suivi ?
Pour notre placard, je voudrais retrouver la seconde visite, le résultat concernant la porte restante et les éventuelles questions encore ouvertes. Si l’artisan fournit une référence de pièce ou une indication pour l’entretien, je l’associerais à l’équipement concerné.
Terminer le suivi ne signifie pas effacer l’ancien rendez-vous ou la première intervention partielle. Ces informations expliquent pourquoi le travail a nécessité plusieurs étapes. Elles peuvent aussi rendre un document ultérieur compréhensible sans me demander de reconstruire toute la chronologie.
Je pourrais finir par une phrase simple : « Les deux portes ont été traitées lors de deux visites ; la référence de la pièce figure avec la seconde intervention. » S’il reste un problème, la phrase devrait le dire. Un libellé doit suivre les éléments disponibles, sans masquer la question encore en suspens.
Quelques semaines plus tard, je devrais pouvoir expliquer pourquoi le dossier contient deux interventions mais un seul travail. C’est le test de cette organisation. Je cherche une histoire compréhensible après l’oubli des conversations récentes, pas seulement un écran qui semble complet aujourd’hui.
La capture, l’accès au dossier et le travail restent distincts
PropertyOS décrit une assistance documentaire locale dont les suggestions peuvent être examinées avant enregistrement. Je vérifierais les références et les dates à partir du document, surtout lorsqu’elles déterminent à quelle visite rattacher une pièce. Le guide sur la numérisation des papiers du logement développe ce contrôle page par page.
La fiche française vérifiée le 17 septembre 2026 présente PropertyOS 1.0.1 pour iPhone et iPad, sous iOS ou iPadOS 18 ou ultérieur. Les nouveaux utilisateurs et les utilisateurs existants non abonnés bénéficient de sept jours complets à partir de la première ouverture de cette version, sans abonnement créé ni débit automatique. Ensuite, Premium est proposé en abonnement mensuel ou annuel à renouvellement automatique. PropertyOS sur l’App Store français.
La fiche précise que les données restent conservées lorsque Premium prend fin et redeviennent accessibles après abonnement ou restauration des achats. Aucun achat à vie n’est proposé. Je lirais l’offre réellement affichée pour mon territoire au moment de choisir. Ces conditions d’accès ne décrivent ni l’état du chantier ni une mise à jour automatique de son historique.
Pour situer ce cas dans l’ensemble du logement, la présentation du dossier PropertyOS explique les liens entre pièces, équipements et documents. Je commencerais par ce petit travail clairement identifié avant d’importer plusieurs années de papiers mal rattachés.
Dans notre entrée fictive, le résultat utile est une réponse précise : une porte réglée au premier passage, une pièce attendue pour l’autre, une seconde venue, et un rôle compréhensible pour chaque document. PropertyOS fournit un emplacement pour cette mémoire. Sa clarté vient des faits que je prends soin de distinguer.