Portails clients, tableaux de bord, outils internes : des applications web construites autour de votre façon de travailler, pas l’inverse. Première version utilisable en production en six à dix semaines, code et hébergement à votre nom.
Presque toutes les PME en ont un. Il a commencé simple. Aujourd’hui il contient des formules que personne n’ose modifier, trois onglets cachés, et une seule personne comprend vraiment comment il fonctionne. Quand elle est en vacances, l’équipe attend.
Le tableur n’est pas le problème — c’est le symptôme. Il signale un processus réel, spécifique à votre entreprise, qu’aucun logiciel du marché ne couvre. Le remplacer par un logiciel générique force votre équipe à changer sa façon de travailler pour s’adapter à l’outil. Ça marche parfois. Souvent, l’outil est abandonné et le tableur revient.
Un outil sur mesure ne se justifie pas parce que c’est plus beau. Il se justifie quand votre façon de travailler est précisément ce qui vous rend concurrentiel.
La plupart des mandats entrent dans l’une de ces catégories, parfois deux.
Vos clients consultent l’état de leur dossier, téléchargent leurs documents, approuvent une soumission ou déposent une demande — sans appeler personne.
Effet : moins d’appels de suivi, et une image professionnelle qui vous distingue à la vente.
Vos chiffres réels, rassemblés depuis vos systèmes, mis à jour automatiquement. Ventes, marges, heures facturables, dossiers en retard — ce que vous décidez de suivre.
Effet : les décisions se prennent sur des données du jour, pas du mois dernier.
Gestion de dossiers, suivi de production, planification d’équipe, calculateur de soumission : l’outil qui remplace le tableur critique, avec des droits d’accès et un historique.
Effet : le processus cesse de dépendre d’une seule personne.
Une version utilisable d’abord, l’ampleur ensuite. C’est ce qui évite les projets qui n’aboutissent jamais.
On observe le processus actuel, on identifie qui fait quoi, et on définit le plus petit périmètre qui apporte déjà de la valeur. C’est aussi ici qu’on vous dit si un logiciel existant ferait l’affaire.
Un prototype cliquable, sans code fonctionnel derrière. Votre équipe le manipule et signale ce qui cloche. Corriger une maquette prend une heure ; corriger du code en prend dix.
Développement du périmètre convenu, connexions aux systèmes existants, gestion des droits d’accès, revue de sécurité. Livrée en production, utilisée pour de vrai.
Quelques semaines d’utilisation par l’équipe. Ce qui a été construit change toujours un peu au contact du terrain — c’est prévu au calendrier, pas traité comme un imprévu.
Documentation, formation, transfert du dépôt de code. Vous choisissez ensuite : reprendre en interne, confier la maintenance à un tiers, ou nous la laisser. Aucune de ces options n’est pénalisée.
Nous refusons régulièrement des mandats de développement parce qu’un logiciel existant suffisait. Voici comment on tranche :
| Votre situation | Recommandation |
|---|---|
| Un logiciel du marché couvre 80 % du besoin | Achetez-le. On l’intègre à vos autres systèmes. |
| Votre processus est votre avantage concurrentiel | Développez. Un outil générique vous ferait perdre cet avantage. |
| Vos systèmes existent mais ne communiquent pas | Automatisation d’abord, développement seulement si nécessaire. |
| Les abonnements dépassent le coût d’un outil interne | Calculez sur trois ans. Le seuil arrive plus vite qu’on pense. |
| Vous avez besoin d’une fonction que personne n’offre | Développez, mais commencez par cette seule fonction. |
Le mauvais réflexe est de faire développer un « ERP maison » parce que trois logiciels du marché déplaisaient chacun sur un point. Ces projets dépassent systématiquement le budget et finissent abandonnés.
Achetez chaque fois qu’un logiciel du marché couvre 80 % de votre besoin : la facture d’abonnement est presque toujours inférieure au coût de développement et de maintenance. Développez quand votre façon de travailler est justement ce qui vous distingue, quand aucun outil ne relie vos systèmes, ou quand les abonnements par utilisateur deviennent plus chers que l’outil lui-même.
Six à dix semaines pour une première version que votre équipe utilise réellement en production, sur un périmètre réduit volontairement. Nous ne livrons pas un outil complet après huit mois : la première version sert à confronter l’idée à la réalité, et elle change toujours ce qu’on croyait devoir construire.
Le code vous appartient et se trouve dans un dépôt à votre nom, avec la documentation technique et les procédures de déploiement. Nous utilisons des technologies courantes précisément pour qu’un autre développeur puisse reprendre le travail. Aucune licence propriétaire, aucun composant que nous seuls pouvons maintenir.
Vous, sur un compte à votre nom. Nous configurons, documentons et pouvons assurer la maintenance, mais l’infrastructure ne passe jamais par nos comptes. C’est ce qui vous garantit de pouvoir changer de fournisseur sans négocier la récupération de vos propres données.
Chiffrement en transit et au repos, authentification à deux facteurs, journalisation des accès, sauvegardes testées et principe du moindre privilège sur chaque rôle. Nous opérons aussi une division cybersécurité, donc la revue de sécurité fait partie du développement plutôt que d’arriver après coup.
C’est souvent la raison principale du projet. Comptabilité, CRM, inventaire, courriel : si le logiciel expose une interface de programmation, on s’y branche. Sinon, on trouve un pont — import planifié, fichier partagé, ou lecture de la base de données. Le cas « aucune connexion possible » est rare.
Décrivez le processus qui vous pose problème. On vous dit s’il existe déjà un outil pour ça, et sinon, à quoi ressemblerait une première version.
Sites vitrines et corporatifs pensés pour convertir, pas pour décorer.
Se faire trouver par des acheteurs, pas par des curieux.
Devis, factures, relances, CRM — le travail répétitif tourne seul.
Agents et chatbots branchés sur vos vraies données.
Audit, formation et conformité — opérés avec Sequr.