# Mobdie v1.4 — L'ergonomie remise sur les gestes du métier *29 juillet 2026 — 374 tests, 1 739 assertions, suite complète au vert.* --- ## Ce que cette version corrige, en une phrase Aucun des cinq gestes que l'exploitant fait tous les jours ne se faisait en moins de trois écrans. Ils tiennent désormais dans une fenêtre, ouvrable de n'importe où. Et le compte courant d'associé, qui n'avait qu'une moitié de comptabilisation depuis le début, a retrouvé la sienne. --- ## 1. Le compte courant d'associé — d'abord une lacune comptable ### Ce qui manquait La catégorie « Apport associé » existait bien : en entrée, groupe Financement, poste CPC « Financement (hors résultat) ». Rien ne lui répondait en sortie. La conséquence n'était pas cosmétique. Quand un associé reprenait son argent, l'opération devait bien se ranger quelque part : elle allait dans une catégorie d'exploitation, et venait grever les charges de l'exercice. Or un mouvement de compte courant n'est ni un produit ni une charge — c'est un mouvement de dette. La société doit cet argent à son associé ; il figure au passif du bilan, et l'associé peut en demander le remboursement à tout moment. Le faire passer en charge fausse le résultat de l'exercice dans un sens et la dette dans l'autre. ### Ce qui a été fait **La catégorie manquante est ouverte.** « Recouvrement compte courant d'associé » : en sortie, groupe Financement, poste CPC « Financement (hors résultat) » — exactement symétrique de l'apport. Même groupe, même poste, seul le sens change. Ainsi apports et reprises s'annulent dans le résultat et se soldent l'un l'autre au bilan. **L'apport est renommé** « Apport en compte courant d'associé », pour que la paire se lise d'un coup d'œil dans une liste de trente-neuf entrées. Les opérations portent l'identifiant de leur catégorie et non son nom : le renommage ne touche rien d'autre que le libellé. **Les deux sont sans TVA**, et ce n'est pas un oubli : un mouvement de compte courant n'est pas une opération imposable. ### Le repérage, qui ne reclasse rien ``` php artisan mobdie:reperer-cca # à l'écran php artisan mobdie:reperer-cca --csv=… # dans un fichier, pour relire à tête reposée php artisan mobdie:reperer-cca --tout # y compris ce qui est déjà bien rangé ``` La commande cherche dans les sorties du journal ce qui évoque un compte courant : les tournures génériques (« compte courant », « cca », « c/c », « associé », « apport ») et les noms des associés déclarés dans les réglages. Elle rend le numéro, la date, le montant, la catégorie actuelle, le tiers, le libellé, et ce qui a déclenché l'alerte. **Elle ne reclasse rien, et c'est délibéré.** Sur le journal réel, elle remonte **42 opérations pour 129 984,00 DH**, et la lecture montre pourquoi le reclassement automatique aurait été une faute : | Catégorie actuelle | Ce qu'on y trouve | Verdict probable | |---|---|---| | Rémunération associés | « SALAIRE SLAOUI », « renum slaoui » — 30 lignes mensuelles régulières | de vraies rémunérations, à laisser | | Remboursement dette financement | « slaoui », « slaoui pour depot bp », « slaoui pour ruwad » — 12 lignes irrégulières | des reprises de compte courant, à reclasser | Un virement à un associé peut être une reprise de compte courant, une rémunération de gérant ou le remboursement d'une avance de frais. Ces trois cas se comptabilisent différemment, et seul l'exploitant sait lequel s'applique. La commande présente, il tranche. Le reclassement se fait ensuite depuis le journal : on sélectionne les lignes, « Recatégoriser », et c'est fait d'un geste. ### Le solde par associé — un chiffre qui a valeur juridique Nouvel écran **Comptabilité → Comptes courants d'associés** : - ce que la société doit à ses associés, en un chiffre, tous comptes confondus ; - pour chacun : total apporté, total repris, solde dû, nombre de mouvements ; - le relevé chronologique déplié d'un clic, avec **le solde après chaque mouvement** — la seule présentation qui permette de vérifier un compte ; - un export CSV, avec un sous-total par associé : c'est la pièce que réclame le comptable pour justifier le poste au passif du bilan. Chaque mouvement porte l'associé concerné, par un tiers de type **« associé »** — un type qui n'existait pas et sans lequel aucun solde nominatif n'était tenable. Les associés déclarés dans les réglages (`comptabilite.associes`) sont créés à la volée : un apport peut être saisi le premier jour, sans détour par l'écran des tiers. Les opérations sans associé désigné ne sont pas escamotées : elles apparaissent sous « Associé non désigné », en rouge, avec la mention « à rattacher ». Elles comptent dans le total général et se voient — c'est ainsi qu'on les corrige. --- ## 2. Une barre d'actions rapides, accessible de partout ### Le principe Six actions en tête de **chaque** écran, sous la barre du haut. Pas sur le tableau de bord seulement : un raccourci qui oblige à revenir au tableau de bord déplace le trajet au lieu de le supprimer. Chacune ouvre une fenêtre qui se remplit et se valide **sans quitter l'écran courant** — la liste consultée, ses filtres et sa position sont conservés. Chaque bouton n'apparaît que si l'utilisateur a le droit correspondant. Un commercial ne voit aucune action d'écriture, et la barre disparaît entière plutôt que de se montrer vide. | Action | Raccourci | Droit requis | |---|---|---| | Nouvelle opération | ⌘/Ctrl + ⇧ + O | `tresorerie.gerer` | | Nouvelle facture | ⌘/Ctrl + ⇧ + F | `factures.gerer` | | Nouveau contrat | ⌘/Ctrl + ⇧ + C | `contrats.gerer` | | Encaisser une échéance | ⌘/Ctrl + ⇧ + E | `paiements.enregistrer` | | Apport en compte courant | ⌘/Ctrl + ⇧ + A | `tresorerie.gerer` | | Recouvrement de compte courant | ⌘/Ctrl + ⇧ + R | `tresorerie.gerer` | L'écran **Aide & raccourcis clavier** (menu utilisateur) présente les six en tête, avec ce que chacune fait. ### Nouvelle opération — trois attentions venues de l'usage **Les catégories habituelles d'abord.** La liste compte trente-neuf entrées par ordre alphabétique. Sur un trimestre, cinq d'entre elles portent l'essentiel des opérations. Elles sont désormais présentées en premier, dans un groupe « Vos catégories habituelles », calculé sur les trois derniers mois et par sens. Aucune catégorie n'apparaît deux fois — un même identifiant dans deux groupes ferait choisir la liste au hasard. **Le compte se souvient.** On ne change pas de compte en cours de relevé. Le dernier employé est proposé, retenu dans la session. **« En saisir une autre ».** L'interrupteur garde la fenêtre ouverte et lui rend la date, le compte et le sens de la saisie précédente. C'est ainsi qu'on dépouille un relevé bancaire : vingt lignes d'affilée, même jour, même compte. Le sens, le groupe et le poste CPC ne sont jamais saisis à la main : ils viennent de la catégorie. Aucune opération ne peut atterrir dans un poste qui n'est pas celui de sa catégorie. ### Encaisser une échéance — le geste qui rapporte, donc le plus court Il en demandait cinq : ouvrir la liste des clients, trouver la société, ouvrir sa fiche, descendre à l'échéancier, enregistrer le paiement. Il en demande un : on coche, on choisit le compte et la date, on valide. Les échéances non soldées sont triées **par ancienneté** — les plus vieilles d'abord, ce sont celles qu'on encaisse — et la recherche porte sur le nom du client, qui est l'entrée naturelle : on ne connaît pas le numéro de l'échéance, on connaît le client qui vient de payer. Plusieurs échéances peuvent être cochées ensemble. À la validation : l'échéance passe payée, l'écriture de trésorerie est créée — une seule, par le paiement, qui reste l'unique fait générateur —, la commission du commercial est générée selon son barème, et la facture est produite dans la foulée si elle manquait. Une recette encaissée sans facture est un problème fiscal ; la facture est établie **avant** le paiement, qui la solde du même mouvement. ### Nouveau contrat — sans repasser par l'assistant L'assistant de création de dossier fait très bien son travail pour un nouveau client. Pour un renouvellement sur une société déjà au fichier, ses cinq étapes sont quatre de trop : tout est connu sauf la périodicité, le montant, la date de début et la durée. L'échéancier s'affiche avant validation, recalculé à chaque frappe : nombre d'échéances, montant unitaire TTC et HT, dates, total du contrat. C'est le même calcul que le générateur d'échéances — aucune surprise après coup. La référence suit le rang du contrat dans le dossier (`2026-07-C1`, puis `-C2`) : un renouvellement se lit dans la liste sans ouvrir les dates. ### Apport et recouvrement de compte courant — deux champs et c'est fait Deux actions distinctes, chacune avec sa catégorie posée d'avance et non modifiable : c'est ce qui les distingue de la saisie ordinaire. Il ne reste que l'associé, le montant, la date et le compte. L'associé est le seul champ sans valeur par défaut, car c'est lui qui donne son sens au mouvement. Un associé absent de la liste se crée dans la fenêtre, sans en sortir. La notification rend le solde du compte courant après l'opération. --- ## 3. La facturation, remise dans le sens du travail ### Le renversement L'écran de création partait d'un formulaire vide : un client à choisir, un objet à écrire, des lignes à composer. Ce n'est pas le geste réel. On ne crée pas une facture, on **facture quelque chose** : une échéance de domiciliation qui arrive, un devis que le client a accepté, une prestation ponctuelle. Les deux premiers cas — l'écrasante majorité — contiennent déjà tout ce qu'il faut. Les retaper, c'est se donner l'occasion de se tromper. La fenêtre demande donc d'abord **d'où l'on part**, puis ne réclame que ce que le point de départ ne sait pas : - **depuis une échéance** : rien à saisir. Client, désignation, période, montant, TVA en découlent. L'exploitant relit et valide ; - **depuis un devis accepté** : les lignes du devis sont reprises telles quelles. La transformation existait déjà, mais seulement depuis l'écran des devis — elle est maintenant visible depuis la facture ; - **prestation ponctuelle** : formulaire libre, avec les désignations les plus employées en suggestion (les lignes de domiciliation en sont écartées : elles portent la période dans leur libellé et ne se répètent jamais à l'identique). Les mêmes trois portes se retrouvent en tête de la liste des factures et en tête du formulaire complet, qui reste disponible pour une facture à plusieurs lignes ou à conditions particulières. ### Ce qui manquait à l'usage quotidien **La duplication.** Mêmes lignes, mêmes conditions, nouveau numéro, date du jour. Le lien vers l'échéance n'est pas repris : une échéance ne se facture qu'une fois, et la copie sert précisément à facturer autre chose de semblable. **L'avoir.** Une facture émise à tort ne s'efface pas — une pièce numérotée reste dans la séquence, sans quoi la numérotation aurait un trou et l'administration y verrait une facture dissimulée. Elle s'annule par une pièce de sens inverse, qui porte sa propre série (`AV-2026-0001`), désigne la facture qu'elle corrige, et dont les montants sont négatifs. Les deux pièces coexistent et se compensent, c'est ce que le comptable attend de voir. Un motif est demandé : un avoir sans motif se justifie mal en contrôle. **La facturation groupée.** Un client qui règle trois trimestres d'un coup ne veut pas trois factures : il en veut une, avec trois lignes — et son comptable non plus. Disponible en action de lot sur l'échéancier global et sur l'échéancier d'un client. Toutes les échéances doivent appartenir au même client : une facture adressée à l'un et facturant l'autre est refusée plutôt que produite. **Le passage direct de « émise » à « encaissée ».** L'action refusait jusqu'ici d'agir sur une facture rattachée à une échéance : elle renvoyait vers l'échéancier du client, de peur que le journal ne compte deux fois le même encaissement. La crainte était fondée, la réponse ne l'était pas — elle faisait traverser trois écrans pour éviter un doublon qui ne se produisait pas. Le doublon viendrait d'une écriture créée en parallèle de celle du paiement. Il suffit donc de ne pas en créer : l'action enregistre un paiement rattaché à l'échéance, et c'est ce paiement — unique fait générateur — qui produit l'écriture, solde l'échéance, solde la facture et génère la commission. **Un seul chemin d'écriture, deux portes d'entrée.** Pour une facture groupée, un paiement est créé par échéance, pour son propre montant. Et la facture n'est soldée que lorsque **toutes** ses échéances le sont : une facture encaissée derrière deux trimestres restés en retard serait un mensonge sur deux écrans à la fois. ### La liste - **Filtre « à encaisser »**, en tête : c'est la question du matin. Il exclut les avoirs, qui ne s'encaissent pas. - **Totaux en pied de colonne** : nombre de pièces, total HT, total TTC — sur l'ensemble filtré, pas sur la page. - **Relance d'un impayé en un clic** : prépare une relance par échéance en retard du client et la met en file. Aucun e-mail ne part sans validation. - Un **filtre de nature** (factures / avoirs) et un badge « Avoir » qui dit quelle facture la pièce annule. --- ## 4. Les clients venus par un comptable ### Le constat Sur le fichier réel, **103 clients sur 114** n'ont ni téléphone ni e-mail. Ni les pièces déposées, ni la boîte Gmail, ni le carnet de 4 646 contacts ne les contiennent. Ce n'est pas une négligence de saisie. Beaucoup de ces sociétés ont été amenées par un comptable ou un cabinet, qui reste l'interlocuteur réel du dossier. Le client final n'a jamais donné ses coordonnées parce que ce n'est pas lui qu'on appelle. ### L'apporteur Une fiche : raison sociale du cabinet, nature (comptable, cabinet comptable, avocat, conseil), nom de la personne qu'on appelle, téléphone, e-mail, adresse, ICE, notes. Chaque client de domiciliation peut y être rattaché — depuis sa fiche, ou en lot depuis la liste des clients. Le rattachement a quatre conséquences réelles, sans quoi il ne servirait à rien. **Les envois partent au bon endroit.** Quand le client a une adresse propre, la relance lui part — c'est son impayé — et l'apporteur en reçoit copie : c'est lui qui fera bouger les choses. Quand le client n'en a pas, elle part à l'apporteur, avec en copie toute autre adresse que le dossier connaît. Sans ni l'un ni l'autre, la relance est préparée sans destinataire et attend qu'on lui en donne un — elle ne part pas dans le vide. **Le message s'adapte.** On n'écrit pas à un comptable comme à son client. Un en-tête paramétrable (`relances.entete_apporteur`) le présente le dossier et lui demande de transmettre, avant le corps habituel de la relance. Il dispose des variables `{{apporteur}}`, `{{cabinet}}`, `{{client}}`, `{{societe}}`. La file d'envoi signale « Via l'apporteur » : ce n'est pas le même courrier, et il faut le savoir avant de valider. **La complétude compte juste.** Un dossier n'est pas injoignable parce que le gérant ne décroche pas : il l'est quand personne ne répond. Un client dont l'apporteur a un téléphone ou une adresse est tenu pour joignable, et l'écran « Dossiers incomplets » cesse de le compter parmi les sans-contact. **Le portefeuille se voit.** Écran **Domiciliation → Apporteurs** : par cabinet, nombre de clients, encours facturé, impayés. C'est une information commerciale que l'exploitant n'avait pas — savoir quel comptable lui amène le plus d'affaires, et lequel a le plus d'impayés. Un cabinet qui apporte dix sociétés dont six ne paient pas n'est pas un bon apporteur, et cela ne se voyait nulle part. ### La résorption, par paquets Sur la liste des clients : un filtre **« Sans apporteur et sans coordonnées »** — qui est exactement le chantier —, une action de lot **« Rattacher à un apporteur »**, et la possibilité de créer le cabinet dans la fenêtre de rattachement. On sélectionne les dix sociétés venues du même cabinet, on les rattache d'un geste, et les dix deviennent joignables du même coup. C'est ainsi que les cent dossiers muets se résorbent : non pas un par un, mais par paquets de dix. --- ## 5. Le RC ne pèse plus lourd ### Ce qui a changé La v1.3.8 avait rendu le registre du commerce exigible seulement après le délai de l'article 544-2 — trois mois. Passé ce délai, il redevenait un manque comme les autres et faisait chuter le pourcentage, colorant en rouge des dossiers par ailleurs irréprochables. Or tous les champs ne se valent pas. **Sans l'identité du domicilié, sa CIN, son adresse, son activité et les deux lieux, le dossier n'existe pas** : c'est ce que le contrôleur vient vérifier au titre de l'article 544-1. Le RC, sa ville et le tribunal se complètent après coup, souvent des mois plus tard, et leur absence ne rend le dossier ni irrégulier ni inexploitable. Les champs sont donc désormais de deux natures : | | Ce que c'est | Effet | |---|---|---| | **Indispensables** | identité, CIN, adresse, activité, siège, les deux lieux, ICE, et les pièces obligatoires | font le pourcentage | | **Souhaitables** | RC, ville du RC, tribunal | apparaissent « à compléter », ni au numérateur ni au dénominateur | **Un dossier auquel il ne manque que le RC est conforme, à 100 %, avec une simple mention à côté.** La mention dit où en est le délai légal : « RC — à compléter (délai jusqu'au 01/04/2026) », puis « (délai d'immatriculation écoulé le 01/04/2026) ». ### Le contrôle légal ne bouge pas Passé le délai, `ConformityService` lève toujours l'alerte `rc_manquant`, en rouge, dans les alertes de conformité. C'est là qu'elle a sa place — c'est là que se joue la responsabilité du domiciliataire au titre de l'article 544-4 — et une alerte se traite, quand un pourcentage se contemple. ### Sur les chiffres réels Complétude moyenne des 100 dossiers suivis : **64 % → 66 %**. 81 dossiers portent désormais une mention « à compléter » au lieu d'un manque. La hausse est modeste, et c'est normal : le pourcentage change aussi d'échelle, puisque trois champs quittent le dénominateur. Un dossier qui avait son RC perd les points qu'il en tirait, et son pourcentage baisse un peu. C'est un effet voulu — le pourcentage ne mesure plus que l'indispensable, et il ne peut plus être flatté par des champs annexes pendant que des pièces obligatoires manquent. L'assistant de création, lui, cesse d'afficher « Exigé par la loi 15-95 » en rouge sous le RC, sa ville et le tribunal : réclamer un registre du commerce à qui se domicilie précisément pour s'immatriculer, c'est réclamer l'impossible. --- ## 6. Recette **374 tests, 1 739 assertions, suite complète au vert.** `./vendor/bin/pint` : propre. Quatre fichiers de recette ajoutés : **`ActionsRapidesTest`** (15 tests) — un test par action rapide, chacune appelée sur le composant qui porte la barre, plus la vérification que la barre est bien rendue sur six écrans de nature différente (tableau de bord, liste de ressource, page sur mesure, écran d'administration) et qu'elle disparaît pour un commercial. On y trouve notamment : - l'encaissement crée l'opération de trésorerie — **une seule** —, la commission du commercial selon son barème, et la facture soldée dans la foulée ; - le solde d'un compte courant après une série de quatre apports et recouvrements, vérifié au dirham près, avec le solde intermédiaire après chaque mouvement (`50 000 → 30 000 → 60 000 → 55 000`) ; - le compte courant reste hors du résultat de l'exercice : ni produit, ni charge, résultat inchangé. **`ApporteursTest`** (8 tests) — la relance d'un client sans e-mail part bien à son apporteur, avec l'en-tête qui s'adresse à lui ; celle d'un client qui a son adresse lui part, apporteur en copie ; un client muet dont l'apporteur répond est tenu pour joignable ; le rattachement de dix sociétés d'un seul geste. **`FacturationV14Test`** (11 tests) — facturation groupée et son refus des clients mêlés, encaissement direct sans ressaisie (une écriture par échéance, jamais deux), duplication, avoir de sens inverse, filtre « à encaisser ». **`CompteCourantAssocieTest`** (6 tests) — les deux catégories symétriques, la disparition de l'ancien nom, et le repérage qui ne reclasse rien. **`CompletudeExigibleTest`** a été réécrit sur le nouveau contrat : le RC ne compte plus, ni avant ni après le délai, et un dossier auquel il ne manque que lui est compté conforme. --- ## 7. Migrations Trois, toutes idempotentes et réversibles. | Migration | Ce qu'elle fait | |---|---| | `ouvrir_le_compte_courant_associe` | renomme l'apport, crée le recouvrement, déclare les associés dans les réglages | | `creer_les_apporteurs` | table `apporteurs`, `domiciliation_clients.apporteur_id`, `relance_queue.via_apporteur` | | `permettre_avoir_et_modeles_apporteur` | `invoices.avoir_de_invoice_id`, série des avoirs, en-tête apporteur | Le retour arrière ne supprime la catégorie de recouvrement que si aucune opération ne s'y range : une écriture comptable ne perd pas sa catégorie en revenant en arrière. Deux onglets s'ouvrent en plus dans les **Réglages** : « Modèles de relance » et « Modèles d'e-mail » — leurs textes existaient en base sans aucun écran pour les afficher, et n'étaient donc modifiables que par la console — et « Comptabilité », qui porte la liste des associés. --- ## Ce qui reste à faire, et qui appartient à l'exploitant **Trancher les 42 opérations repérées.** La commande les présente, le journal permet de les recatégoriser en lot. Notre lecture : les 12 lignes « Remboursement dette financement — slaoui » sont très probablement des reprises de compte courant ; les 30 lignes « Rémunération associés » sont très probablement de vraies rémunérations. C'est une lecture, pas une décision. **Rattacher leur associé aux opérations reclassées.** Sans tiers, le solde par associé ne peut pas être tenu, et le poste au passif reste un total sans titulaire. **Créer les apporteurs et rattacher les cent dossiers muets.** Le filtre « Sans apporteur et sans coordonnées » donne la liste ; l'action de lot fait le reste, par paquets de dix.