Scénarios de Facturation Réels

La vie de facturation de chaque freelance est plus désordonnée qu’un fichier de config propre ne le suggère. Les clients changent, les contrats se renouvellent, des erreurs se produisent, et parfois tu fais du travail que tu ne veux pas facturer. Ces scénarios décrivent des situations réelles et comment Vibes to Bucks les gère.

Scénario 1 — Renouvellement de contrat : même client, nouveau projet

Qui : Anna, développeuse freelance travaillant sur github.com/acme/website pour le client Acme.

Ce qui s’est passé : Depuis janvier, Anna facture les coûts AI au projet Moneybird “Acme Website Q1–Q2”. Le 1er juillet, un nouveau contrat de 6 mois commence. Le projet Moneybird du client passe à “Acme Website Q3–Q4” — peut-être avec un taux horaire différent. Le dépôt et la branche restent les mêmes.

Ce qu’Anna veut :

• À partir du 1er juillet, tous les nouveaux coûts AI se synchronisent avec le nouveau projet.
• Les six mois d’entrées de temps déjà dans Moneybird sous l’ancien projet restent exactement là où elles sont.
• Le coût d’aujourd’hui va au nouveau projet.

Le risque sans guidance : Anna modifie sa règle de facturation et exécute Sync Now. L’extension réagrège de janvier à juin, ne voit aucune entrée de temps pour ces jours sous le nouveau projet, et crée 180 entrées en double dans Moneybird — en plus de celles qui existent déjà sous l’ancien projet.

Comment Vibes to Bucks le gère : Quand Anna modifie sa règle de facturation pour pointer vers le nouveau projet, l’extension lui demande ce qu’il faut faire des coûts historiques. Elle choisit “Appliquer à partir d’aujourd’hui”. Les jours passés conservent leur association avec l’ancien projet. Seuls aujourd’hui et les jours futurs se synchronisent sous le nouveau projet. Pas de doublons, pas de nettoyage nécessaire.

Scénario 2 — Changement de client : déplacer un dépôt vers un autre client

Qui : Ben, développeur travaillant sur github.com/org/platform.

Ce qui s’est passé : Ben a initialement facturé ce dépôt au Client Alpha, qui a financé la phase R&D. La plateforme est maintenant en production et le Client Beta est le client actuel. Ben doit remapper le dépôt.

2a — Rupture nette

Ce que Ben veut : Les coûts futurs vont au Client Beta. Les entrées passées synchronisées avec le Client Alpha restent intactes. Rien de rétroactif.

Comment Vibes to Bucks le gère : Ben change le contact de la règle de facturation d’Alpha à Beta. L’extension demande ce qu’il faut faire de l’historique. Il choisit “Appliquer à partir d’aujourd’hui”. Les entrées historiques d’Alpha restent dans Moneybird. Beta commence à recevoir des entrées à partir d’aujourd’hui.

2b — Correction rétroactive complète

Ce que Ben veut : La facturation Alpha était une erreur — tout aurait dû être Beta depuis le début. Ben veut tout resynchroniser sous Beta. Il accepte qu’il devra nettoyer manuellement les entrées d’Alpha dans Moneybird.

Comment Vibes to Bucks le gère : Ben choisit “Appliquer à tout le temps”. L’extension l’avertit que les entrées existantes sous Alpha ne seront pas automatiquement supprimées — il devra les retirer dans Moneybird. Elle crée ensuite de nouvelles entrées pour chaque jour historique sous Beta.

2c — Synchroniser uniquement le décalage

Ce que Ben veut : Ben a arrêté de synchroniser il y a deux semaines lorsqu’il a réalisé que le mapping était incorrect. Il a 14 jours de coûts non synchronisés dans le registre. Il veut que ces 14 jours aillent à Beta, mais que les mois déjà synchronisés avec Alpha restent.

Comment Vibes to Bucks le gère : Ben choisit “Appliquer uniquement aux jours non synchronisés”. L’extension sait quels jours ont déjà une entrée de temps dans provider_posts et les ignore. Seuls les 14 jours non synchronisés sont créés sous Beta.

Scénario 3 — Division de projet : redistribuer le travail entre sous-projets

Qui : Clara, développeuse travaillant sur un monorepo pour le Client Gamma.

Ce qui s’est passé : Clara a facturé tout le travail AI à un projet global “Développement Général”. Gamma veut maintenant que les coûts soient répartis par domaine de fonctionnalité. Clara crée des règles de facturation basées sur les branches : feature/auth/* → “Module Auth” et feature/billing/* → “Module Billing”.

3a — Division uniquement vers l’avant

Ce que Clara veut : À l’avenir, les coûts sont dirigés vers le bon sous-projet. Les coûts passés déjà synchronisés sous “Développement Général” restent là.

Comment Vibes to Bucks le gère : Quand Clara ajoute les nouvelles règles de branche, l’extension demande pour chaque règle ce qu’il faut faire de l’historique. Elle choisit “Appliquer à partir d’aujourd’hui” pour les deux. Les entrées historiques sous “Développement Général” ne sont pas touchées.

3b — Précision historique

Ce que Clara veut : Elle veut en fait déplacer rétroactivement les coûts passés vers les bons sous-projets. Elle accepte qu’elle supprimera manuellement les anciennes entrées “Développement Général” dans Moneybird.

Comment Vibes to Bucks le gère : Clara choisit “Appliquer à tout le temps” pour les nouvelles règles. L’extension avertit des entrées existantes sous l’ancien projet et crée des entrées correctes par sous-projet par jour. Clara nettoie les anciennes entrées dans Moneybird.

Scénario 4 — Travail de courtoisie non facturable

Qui : David, freelance travaillant sur le dépôt du Client Delta.

Ce qui s’est passé : David est impliqué dans une revue de code interne et quelques expérimentations qui ne font pas partie du périmètre de Delta — mais il garde Cursor ouvert sur leur dépôt. Il ne veut pas que les 2 prochaines heures de coût AI soient facturées à Delta.

Ce que David veut :

• Basculer la règle de facturation de Delta en mode “non facturable”. Un indicateur visible dans la barre d’état confirme que la règle est non facturable.
• Les coûts AI sont toujours suivis et visibles sur le tableau de bord — il veut voir ce que ce travail de courtoisie lui coûte — mais marqués comme non facturables.
• Toutes les heures, une notification de rappel : “La règle de facturation Delta est non facturable depuis 2 heures. Toujours en mode non facturable ?”
• Quand il revient à facturable, la synchronisation normale reprend.
• Les coûts non facturables apparaissent sur le tableau de bord sous Delta mais sont clairement distingués des coûts facturables.

Pourquoi par mapping, pas global : David pourrait être multitâche. S’il passe au dépôt du Client Beta pendant que Delta est non facturable, Beta doit toujours être facturé normalement. Non facturable est une décision de courtoisie par client : “ce coût que je fais n’est pas la demande du client — je le fais pour eux par courtoisie.”

Comment Vibes to Bucks le gère : David ouvre le panneau des paramètres et bascule la règle de facturation de Delta en non facturable. Une boîte de dialogue demande deux choses : quand le mode non facturable doit commencer (maintenant, ou rétroactivement), et quand il doit se terminer. David choisit “À partir de maintenant” et “Fin de la journée” — la facturation reprend automatiquement demain. La barre d’état affiche $4.23 aujourd'hui · Delta [non facturable jusqu'à la fin de la journée] pendant qu’il travaille dans le dépôt de Delta. Les coûts non facturables se synchronisent toujours avec Moneybird en tant qu’entrées de temps non facturables (visibles dans les enregistrements mais exclues de la facturation client). Le tableau de bord montre à la fois les coûts facturables et non facturables pour Delta, clairement séparés.

Si David prévoit que le travail de courtoisie dure plus longtemps, il peut choisir “Date spécifique” (par exemple, non facturable jusqu’à vendredi) ou “Jusqu’à ce que je reprenne manuellement” avec un intervalle de rappel (toutes les 30 minutes, 1 heure, 2 heures, etc.) pour ne pas oublier de réactiver la facturation.

Variation — rétroactif non facturable

Ce que David veut : Il a oublié de basculer avant de commencer. Il veut marquer les 90 dernières minutes comme non facturables après coup.

Comment Vibes to Bucks le gère : David ouvre le panneau des paramètres, bascule Delta en non facturable, et sous la section Début choisit “Rétroactif” avec un temps de 90 minutes en arrière. Les coûts à partir de ce moment sont marqués comme non facturables. Si l’entrée de temps d’aujourd’hui a déjà été synchronisée avec Moneybird, l’extension recalcule et met à jour pour refléter le montant facturable réduit. La rétroaction est limitée à aujourd’hui — pour les corrections sur plusieurs jours, le registre de synchronisation offre des contrôles d’annulation et de resynchronisation.

Scénario 5 — Annuler une synchronisation incorrecte

Qui : Eve, freelance qui a changé un mapping et a immédiatement exécuté Sync Now.

Ce qui s’est passé : Eve a modifié une règle de facturation (changé le projet) et a exécuté Sync Now sans réfléchir aux conséquences. L’extension a créé 3 mois de nouvelles entrées de temps sous le mauvais projet dans Moneybird, en plus des entrées correctes existantes sous l’ancien projet.

Ce qu’Eve veut :

• Voir ce qui vient d’être synchronisé — un résumé montrant combien d’entrées ont été créées ou mises à jour, pour quels jours, sous quel projet.
• Annuler : soit l’extension supprime les entrées créées incorrectement, soit elle lui indique clairement quels IDs d’entrée nettoyer manuellement.

Comment Vibes to Bucks le gère : Après chaque synchronisation, l’extension affiche une notification : “Synchronisé avec Moneybird — Créé 87, mis à jour 2, ignoré 14.” En cliquant sur “Afficher les détails”, elle ouvre le Registre de synchronisation — une vue dédiée montrant chaque entrée synchronisée et en attente, filtrable par client, projet et date. Eve peut voir exactement quelles entrées viennent d’être créées, sélectionner les incorrectes, et cliquer sur “Annuler la synchronisation.” L’extension supprime ces entrées de Moneybird et les marque à nouveau comme en attente pour qu’elles puissent être resynchronisées correctement après qu’elle ait corrigé la règle.

Scénario 6 — Facturation temporaire de projet

Qui : Frank, développeur travaillant sur github.com/acme/api.

Ce qui s’est passé : Frank facture normalement au projet “Maintenance API”. Pendant deux semaines en mars, il est sur un sprint spécial facturé à “Migration API v2”. Après le sprint, il revient à la normale.

Ce que Frank veut :

• Changer la règle de facturation pour “Migration API v2” le 10 mars.
• La changer à nouveau pour “Maintenance API” le 24 mars.
• Seule la période du 10 au 23 mars se synchronise avec “Migration API v2”.
• Tout ce qui précède le 10 mars et suit le 23 mars se synchronise avec “Maintenance API”.
• Pas de désordre rétroactif dans un sens ou dans l’autre.

Comment Vibes to Bucks le gère : Chaque fois que Frank change la règle de facturation, il choisit “Appliquer à partir d’aujourd’hui”. Le 10 mars, la règle commence à facturer à “Migration API v2”. Le 24 mars, elle revient à “Maintenance API”. Les entrées de chaque période restent avec le projet actif à ce moment-là.

Scénario 7 — Arrêter la facturation, continuer le suivi

Qui : Gina, freelance qui termine avec le Client Eta.

Ce qui s’est passé : Le contrat est terminé, mais Gina fait encore de petites maintenances sur le dépôt d’Eta. Elle veut voir les coûts AI dans son tableau de bord — pour évaluer si un nouveau contrat vaudrait le coup — mais elle ne veut pas synchroniser d’entrées de temps.

Ce que Gina veut :

• Marquer la règle de facturation comme non facturable de façon permanente (pas un basculement temporaire — un réglage durable).
• Le tableau de bord montre toujours les coûts attribués au Client Eta.
• La synchronisation ignore complètement cette règle de facturation.
• Si Eta revient avec un nouveau contrat, elle la remet en facturable et ne synchronise qu’à partir de ce moment — pas la période de décalage.

Comment Vibes to Bucks le gère : Gina décoche “Facturable” sur la règle de facturation d’Eta. Les coûts continuent d’être suivis et apparaissent sur le tableau de bord sous Eta, mais aucune entrée de temps n’est créée. Quand un nouveau contrat arrive, elle réactive la facturation et choisit “Appliquer à partir d’aujourd’hui”. La période non facturable reste non facturée.

Scénario 8 — Migration de fournisseur

Qui : Hugo, freelance qui synchronise avec Moneybird depuis 6 mois.

Ce qui s’est passé : Le cabinet comptable d’Hugo le passe à Harvest. Il change destination: harvest dans sa config et met en place de nouvelles règles de facturation Harvest.

Ce que Hugo veut :

• À l’avenir, la synchronisation va vers Harvest.
• Les 6 mois d’entrées Moneybird restent intacts.
• Aucune entrée rétroactive créée dans Harvest pour la période historique.

Comment Vibes to Bucks le gère : Quand Hugo change de fournisseur de facturation, l’extension détecte que Harvest n’a pas d’historique de synchronisation. Sans guidance, elle essaierait de créer des entrées pour chaque jour historique. Au lieu de cela, le même dialogue à trois options apparaît : “Commencer à partir d’aujourd’hui”, “Synchroniser tout l’historique”, ou “Synchroniser uniquement les jours non synchronisés.” Hugo choisit “Commencer à partir d’aujourd’hui.” L’extension définit une date de coupure de migration pour que le moteur de synchronisation ignore tous les jours avant aujourd’hui. Seuls aujourd’hui et les jours futurs créent des entrées Harvest. Ses entrées Moneybird restent intactes.

Scénario 9 — Suppression accidentelle de règle

Qui : Ivan, freelance qui facture le dépôt du Client Kappa.

Ce qui s’est passé : Ivan voulait modifier sa règle de facturation pour changer le taux horaire, mais l’a accidentellement supprimée. Il s’en rend compte immédiatement et recrée la règle avec les bons paramètres.

Ce qu’Ivan veut :

• Recréer la règle sans provoquer des mois de doublons d’entrées de temps dans Moneybird.
• Les entrées passées déjà synchronisées doivent rester intactes.
• La facturation doit continuer sans interruption comme si rien ne s’était passé.

Le risque sans guidance : Ivan crée la nouvelle règle. L’extension voit un dépôt avec des données de coût historiques et aucun historique de règle de facturation correspondant. Une synchronisation naïve traiterait chaque jour passé comme “jamais synchronisé sous cette règle” et créerait des entrées pour toute l’histoire.

Comment Vibes to Bucks le gère : Quand Ivan crée une règle de facturation pour un dépôt qui a déjà des données de coût historiques dans le registre, l’extension le reconnaît et présente le même dialogue à trois options. Ivan choisit “Appliquer à partir d’aujourd’hui” — les entrées passées restent telles qu’elles étaient, et la facturation reprend à partir d’aujourd’hui. Pas de doublons, pas de décalage, pas de panique.

Le fil conducteur

Chaque scénario ci-dessus se résume à une question : quand tu changes une règle de facturation, que doit-il se passer pour le passé ?

Vibes to Bucks ne prend jamais cette décision pour toi. Chaque fois que tu modifies une règle de facturation — change le client, le projet, le taux ou le statut facturable — l’extension te demande de choisir :

Ce choix guidé apparaît dans un dialogue clair chaque fois qu’un changement de règle de facturation affecterait la gestion des coûts historiques. Pas de surprises, pas de refacturation rétroactive silencieuse, pas de doublons orphelins.