Cockpit : l’outil de gestion qui a remplacé nos tableurs.

01Avant le projet.

Le contexte.

Chez OTTOPILOTE, tout se tenait dans des tableaux : prospects, facturation, suivi des clients. Piloter plusieurs sociétés avec Notion, Excel, un CRM et un outil de facturation, c’est des données éparpillées, de la double saisie et aucune vue d’ensemble : chaque chiffre demande un export manuel.

Pour gagner du temps, on a remplacé ces tableaux par nos propres outils : un ERP à nos règles, plutôt qu’un abonnement de plus. Le cas raconté ici est donc le nôtre, erreurs comprises.

02Le périmètre livré.

Ce qu’on a construit.

1. 01

   CRM et pipeline

   Le premier module métier, écrit le 5 juin 2026, au lendemain du démarrage.

2. 02

   Propositions, contrats, factures

   Une proposition devient un contrat, puis des factures et des échéanciers. Cinq chemins différents fabriquent une facture ou un revenu à partir d’une proposition.

3. 03

   Finances

   TVA, compte de résultat mensuel sur base encaissement, trésorerie sur 12 mois, commissions : pour chaque société, et en vue consolidée.

4. 04

   Agenda consolidé

   Rendez-vous, tâches et échéances de toutes les sociétés sur un seul agenda, synchronisé avec Google Calendar et réconcilié chaque matin.

5. 05

   Rapports SEO des clients

   Générés automatiquement le 3 du mois : synthèse, clics, impressions, sessions, position, plan d’action, puis export PDF.

6. 06

   Ce qui tourne tout seul

   18 tâches planifiées : factures du jour émises à 6 h, suivi de nos projets GitHub mis à jour, données Search Console et Analytics relevées chaque nuit, articles de notre chaîne de publication vérifiés en ligne chaque matin.

03Ce qu’il y a dessous.

La stack.

• Next.js + React72 pages, en ligne sur Vercel
• SupabaseAuto-hébergée sur notre serveur : comptes et données
• GoogleCalendar, Search Console et Analytics branchés
• PDFPropositions, contrats, factures et rapports mis en PDF automatiquement

04Daté, incidents compris.

Le déroulé, daté.

1. 04/06/2026

   « Phase 0 », le démarrage

   Le projet démarre. Le lendemain, 5 juin, le CRM devient le premier module métier.

2. 20/08/2026

   Une panne que personne ne voit

   Le module GitHub tombe en panne et le reste jusqu’au 20/09/2026. La tâche planifiée échouait tout en répondant « tout va bien » : une vraie erreur aurait déclenché une alerte.

3. 03/09/2026

   Les remises, sur tous les chemins

   Cinq chemins fabriquent une facture ou des revenus depuis une proposition : découper une proposition en plusieurs factures aurait appliqué la remise autant de fois. Vérifié : avec une remise de 1 500 $ sur le ponctuel, une facture qui reprend la moitié du ponctuel porte 750 $, pas 1 500 $. Même chantier : la première version imprimait la remise sur le contrat mais laissait « Total contract value » inchangé, alors que sur un document juridique, c’est le total qui fait foi. Attrapé par un rendu de contrôle, pas par la relecture du code.

4. 04/09/2026

   285 px de proposition perdus

   La page A4 du modèle de proposition avait une hauteur figée, et ce qui dépassait était coupé sans un mot. Mesuré sur une vraie proposition : 285 px de contenu perdus, exclusions comprises.

5. 05/09/2026

   Une police jamais chargée

   Le document de proposition ne chargeait aucune police : « Archivo » retombait sur la police système chez tous les clients. Le devis n’avait jamais été rendu dans sa typographie.

6. 08/09/2026

   Un abonnement compté sur douze mois

   Une proposition d’abonnement à 300 €/mois sans engagement affichait « Sous-total 3 600 € » et « Remise − 1 800 € », soit douze mensualités que le client ne s’engage pas à payer. Elle affiche désormais « 300 €/mois » et « − 150 €/mois ».

7. 20/09/2026

   Cockpit « rame »

   Mesure : chaque échange entre l’application et sa base de données prend 86 ms, dix à la suite 850 ms, alors que la base elle-même répond en 0,3 ms. Application rapprochée de la base : 28 ms. Pour afficher une page, 3 attentes en cascade au lieu de 7.

8. 02/10/2026

   Le recompte

   72 pages et 18 tâches planifiées, quatre mois après le démarrage.

05Mesurés ou vérifiables.

Les résultats, mesurés.

06Le retour d’expérience.

Ce qu’on referait différemment.

1. 01

   Surveiller le résultat, pas le message de réussite

   Pendant un mois, le module GitHub a répondu « tout va bien » tout en échouant. Dès la première tâche planifiée, on ferait échouer franchement tout traitement qui n’a pas fait son travail : c’est l’erreur qui déclenche l’alerte. Voir aussi le monitoring.

2. 02

   Mesurer avant d’optimiser

   Quand Cockpit a ralenti, la piste évidente était la base. Alléger les requêtes : mesuré, zéro gain. Le temps était dans les 1 300 km entre l’application et sa base. On choisirait où placer l’une et l’autre avant d’écrire la première requête.

3. 03

   Rendre chaque document avant de le livrer

   Un total qui ne bouge pas, 285 px qui disparaissent, une police jamais chargée : aucun de ces défauts ne se voyait en lisant le code. On ferait un rendu de contrôle sur une vraie proposition dès le premier modèle de document.

4. 04

   Tester les remises sur les cas qui fâchent

   Facture partielle, abonnement sans engagement : ce sont ces deux cas qui ont faussé les montants. On les écrirait en tests avant d’envoyer la première proposition.

07Avant de nous écrire.

Pour qui ce type de projet est pertinent.

Cockpit est notre outil interne. Pour votre activité, la même démarche s’appelle un logiciel métier sur mesure ; si vos tableurs arrivent à leur limite, notre guide pour migrer d’Excel vers un logiciel métier détaille les étapes.