Comment j'ai transformé Invoice Ninja en plateforme complète de relation client

Au départ, je cherchais simplement un logiciel de devis et de facturation pour mon activité de développeur web freelance. Je voulais une solution auto-hébergée, moderne, avec un portail client, une API, une architecture ouverte et une vraie base technique. Invoice Ninja répondait très bien à ces critères.

Je précise volontairement les choses dès le début: je ne suis pas l'auteur d'Invoice Ninja, je ne revends pas Invoice Ninja et je ne présente pas ce travail comme un produit concurrent. Invoice Ninja reste la solution de base. Mon travail a consisté à construire, pour mes propres besoins professionnels, une série de modules autour de cette base afin d'en faire le centre de ma relation client.

Avec le temps, la facturation est devenue un module parmi d'autres. L'outil sert toujours à gérer les devis et les factures, mais il centralise aussi la maintenance, les applications clients, les documents, les réunions, les tickets, certains secrets partagés, des contrôles de conformité et une partie de la préparation à la facturation électronique française.

Pourquoi partir d'Invoice Ninja

Développer un logiciel complet depuis zéro aurait été possible, mais peu rationnel. La facturation est un domaine exigeant: modèles de données, statuts, taxes, paiements, relances, portail client, PDF, emails, API, sécurité, droits d'accès. Invoice Ninja apportait déjà une base mature, maintenue, documentée et pensée pour l'auto-hébergement.

Le bon choix n'était donc pas de refaire ce qui existait déjà. Le bon choix était de comprendre l'architecture, d'identifier les points d'extension possibles, puis de construire les modules manquants avec une contrainte forte: garder la capacité de suivre les évolutions du projet officiel.

Cette décision raconte assez bien ma façon de travailler sur une application métier: je ne cherche pas systématiquement la réécriture. Quand une base est saine, je préfère l'étendre proprement, limiter les risques et concentrer l'effort sur ce qui crée réellement de la valeur.

Les besoins apparus au quotidien

Après quelques mois d'utilisation, mes besoins dépassaient la simple émission de devis et de factures. Je voulais répondre plus vite aux clients, mieux suivre les applications en maintenance, conserver un historique exploitable, préparer les interventions, centraliser les documents et éviter la dispersion entre plusieurs outils.

J'ai donc commencé à construire des modules ciblés:

• un tableau de bord client plus riche;
• un portail client modernisé;
• un suivi de maintenance applicative;
• des contrats et documents liés à la maintenance;
• un historique des interventions;
• des indicateurs de santé des applications;
• des tickets support avec contexte technique;
• des notes de réunion collaboratives;
• un module de partage sécurisé de secrets, sans stockage de la clé de déverrouillage;
• des contrôles de documents de conformité;
• une intégration Abby pour synchroniser certains éléments de facturation;
• des automatisations, notifications et contrôles via API.

L'objectif n'était pas d'empiler des fonctionnalités. L'objectif était de créer une plateforme cohérente, centrée sur la relation client et alignée avec ma manière de travailler.

Pourquoi Laravel

Invoice Ninja repose sur Laravel côté backend. C'était un avantage important: les modules pouvaient s'intégrer naturellement avec les providers, les routes, les migrations, les policies, les modèles Eloquent, les services, les événements, les notifications et les tests.

J'ai conservé cette logique. Chaque extension importante vit dans un module isolé, avec ses routes admin, client ou api, ses migrations, ses services applicatifs et ses tests quand le comportement métier le justifie.

Cette organisation permet de raisonner module par module. Par exemple, le module de maintenance applicative gère ses propres applications maintenues, contrats, interventions, alertes, vulnérabilités, contrôles de sauvegarde et automatisations. Le module de notes de réunion gère ses modèles, événements, API et mécanismes collaboratifs. Le partage sécurisé de secrets reste isolé autour de son propre service métier.

Pourquoi React

Je n'ai pas choisi React par effet de mode. Invoice Ninja utilise déjà React pour son interface d'administration. Il était donc logique de suivre cette architecture afin que mes développements restent intégrés, cohérents et maintenables dans le contexte du projet.

Ce choix évite de créer une expérience parallèle qui ne parlerait pas le même langage que l'application. Les dashboards, vues de maintenance, écrans documentaires et composants interactifs peuvent reprendre les mêmes conventions d'interface, le même pipeline d'assets et les mêmes habitudes de navigation.

Dans une application métier, la cohérence compte autant que la technologie. Un outil que l'on utilise tous les jours doit être lisible, prévisible et rapide à parcourir.

Les WebSockets et le temps réel

Certains usages gagnent beaucoup à devenir temps réel. Les notes de réunion en sont un bon exemple: quand une réunion se déroule avec un client, une note collaborative synchronisée évite les copier-coller, les versions divergentes et les comptes rendus reconstruits après coup.

Ce module répond aussi à une volonté plus large: sortir progressivement de la suite Google quand c'est pertinent et centraliser davantage d'informations dans un seul espace pour mes clients. L'idée n'est pas de tout remplacer brutalement, mais de ramener les usages récurrents, comme les comptes rendus, les notes partagées et le suivi client, dans un environnement que je maîtrise davantage.

J'ai donc ajouté une brique WebSocket pour les fonctionnalités qui le justifient:

• synchronisation de notes collaboratives;
• notifications instantanées;
• rafraîchissement d'informations opérationnelles;
• meilleure continuité entre portail client et interface interne.

Le temps réel n'est pas là pour faire moderne. Il apporte du confort lorsque plusieurs personnes regardent ou modifient la même information. Pour un client, cela donne aussi le sentiment d'un outil vivant, dans lequel les échanges ne sont pas perdus dans une suite d'emails.

Le plus gros défi: rester compatible avec les mises à jour

Le plus gros défi n'a pas été de développer les fonctionnalités. Le vrai sujet était de conserver la possibilité de mettre Invoice Ninja à jour sans casser les développements.

Pour y parvenir, j'ai travaillé avec plusieurs règles:

• limiter les modifications du cœur;
• isoler les ajouts dans des modules Laravel;
• déclarer les routes et providers proprement;
• encapsuler la logique métier dans des services;
• versionner les migrations;
• séparer les composants React ajoutés;
• utiliser des scripts d'installation et de build;
• documenter les points d'intégration;
• réduire les conflits Git lors des mises à jour;
• garder une stratégie de maintenance plutôt qu'une suite de patchs ponctuels.

Cette contrainte change la façon de coder. On ne cherche pas seulement à faire fonctionner une fonctionnalité aujourd'hui; on cherche à faire en sorte qu'elle continue d'exister demain, quand le socle évoluera.

Les modules construits autour de la facturation

La plateforme s'est organisée autour de plusieurs familles de modules.

Maintenance applicative

Le suivi de maintenance permet de rattacher des applications à des clients, de suivre les interventions, contrats, alertes, recommandations, vulnérabilités, composants, sauvegardes et contrôles périodiques.

Ce module transforme une prestation récurrente en système traçable. Je peux retrouver ce qui a été fait, ce qui reste à surveiller, les risques identifiés et les éléments à préparer pour un prochain échange client.

Portail client enrichi

Le portail client ne sert plus uniquement à consulter une facture. Il devient un centre de relation: documents, tickets, notes, informations de maintenance, suivi applicatif, éléments contractuels et données utiles au quotidien.

Cette évolution est importante: le client n'a pas besoin d'apprendre un nouvel outil pour chaque sujet. Il retrouve les informations dans un espace déjà lié à sa relation commerciale.

Réunions et notes collaboratives

Le module de réunions permet de conserver des notes liées au contexte client. Avec la synchronisation collaborative en temps réel via WebSockets, les informations peuvent être partagées et mises à jour plus naturellement pendant les échanges, sans dépendre systématiquement d'un document Google externe ni disperser le suivi client entre plusieurs outils.

Ce type de module paraît simple en surface, mais il touche à des sujets intéressants: droits d'accès, diffusion d'événements, persistance de l'état collaboratif, restitution lisible, rattachement aux clients et souveraineté progressive sur les outils de travail quotidiens.

Partage sécurisé de secrets

Le partage de mots de passe ou de secrets techniques ne devrait pas passer par email ou messagerie instantanée. J'ai donc ajouté un module de partage sécurisé conçu autour du chiffrement côté navigateur et d'un périmètre fonctionnel volontairement limité.

Ce module ne stocke pas la clé de déverrouillage. Elle reste dans le fragment de l'URL, après #, et n'est donc pas envoyée au serveur. Le contenu chiffré transite côté Laravel, mais le déchiffrement se fait dans le navigateur du client.

L'objectif est simple: transmettre une information sensible sans la banaliser, avec une expérience compréhensible pour un client non technique.

Documents de conformité et facturation électronique

La préparation à la facturation électronique française impose de mieux structurer certains documents et flux. J'ai ajouté des briques autour des documents de conformité, avec récupération, rafraîchissement et suivi de statuts quand c'est pertinent.

Ce n'est pas une promesse de remplacer les futurs outils réglementaires. C'est une manière de préparer progressivement la plateforme à mieux organiser les informations nécessaires.

Tickets support et contexte technique

Le support est plus efficace quand la demande arrive avec le bon contexte. Les tickets peuvent donc guider le client pour transmettre les informations utiles, tout en conservant l'historique dans le même environnement que les devis, contrats, maintenances et documents.

Architecture technique

La stack repose principalement sur:

• Laravel pour le backend;
• PHP et Eloquent pour le modèle métier;
• React et TypeScript pour les interfaces dynamiques;
• API REST pour les échanges internes et externes;
• WebSockets pour les usages collaboratifs;
• MySQL pour la persistance;
• Git et GitLab CI pour le suivi et l'industrialisation;
• Docker/DDEV pour l'environnement local;
• scripts de build, migrations et commandes Laravel pour les opérations récurrentes.

L'intérêt de cette architecture est sa lisibilité. Chaque module répond à un besoin métier clair, mais s'appuie sur les conventions existantes de l'application.

Ce que cette expérience démontre

Ce projet est devenu un outil quotidien, mais c'est aussi une bonne démonstration de compétences full-stack sur une application existante importante:

• comprendre une base Laravel réelle;
• respecter une architecture existante;
• concevoir des modules maintenables;
• intégrer React sans rupture d'expérience;
• créer des workflows client concrets;
• gérer les droits, routes, assets, migrations et tests;
• préparer une stratégie de mise à jour;
• transformer une contrainte métier en interface utilisable.

Pour un prospect, c'est probablement le point le plus important: je sais reprendre une application existante, comprendre son architecture et la faire évoluer proprement sans compromettre les futures mises à jour.

Résultat

Aujourd'hui, Invoice Ninja reste la base de facturation de mon activité. Autour de cette base, j'ai construit une plateforme métier qui me permet de gérer les devis, factures, maintenances, applications, projets, documents, réunions, demandes support et informations sensibles dans un environnement cohérent.

La facturation n'a pas disparu. Elle a simplement retrouvé sa bonne place: un module essentiel, intégré à un système plus large de relation client.

Ce projet n'a pas vocation à devenir une revente d'Invoice Ninja. Il raconte plutôt une compétence: savoir partir d'un excellent socle open source, le respecter, l'étendre, et construire autour de lui des outils métier solides.