Machine en verre et métal noir transformant une multitude de documents dispersés en un flux opérationnel unique.

Produit & logiciel

Développement logiciel et applications métier sur mesure

La plupart des entreprises ne souffrent pas d’un manque de logiciels. Elles souffrent de logiciels qui ne parlent pas entre eux, et de tableurs qui font tenir le reste.

Parler de votre projet Estimer mon projet

Expertise: Produit & logiciel
Nature: Application interne, back-office, outil métier
Périmètre: Cadrage · produit · interfaces · architecture
Socle: TypeScript · PostgreSQL · API documentée
Propriété: Code, données et documentation livrés

Cadrer la mission

Le projet en pratique

Pour qui: PME qui doublent les saisies, dépendent d’un tableur critique ou doivent relier leurs outils existants.
Ce qui est livré: Cartographie d’un processus, périmètre prioritaire, interface, règles métier, droits d’accès et recette. La reprise des données et les connexions sont préparées selon les systèmes concernés.
Budget et conditions: 12 000 € – 16 000 € HT
Repère du simulateur pour un logiciel métier standard. Les rôles, migrations, interfaces et contraintes de déploiement déterminent le devis.
Estimer mon projet Comprendre les fourchettes
Ce que le devis précise: Le cadrage compare conserver, connecter ou remplacer. Code, données et documentation sont remis selon le devis ; licences, exploitation et évolutions sont distinguées du développement initial.

Du tableur au suivi de devis : un scénario complet

Un exemple de spécification, pas un résultat client. Première décision : conserver le tableur, le connecter ou remplacer la partie du travail que l’équipe partage.

1
Importer et faire correspondre
Un CSV contient référence client, numéro de devis, montant, date et statut. Chaque colonne correspond à un champ typé ; la référence source est conservée. Dates invalides et numéros en doublon sont signalés avant toute écriture.
2
Valider et définir les droits
Le commercial consulte ses dossiers, un responsable valide l’import et seuls les rôles autorisés modifient les montants. Un aperçu distingue créations, mises à jour et rejets. Un rapprochement client ambigu attend une vérification.
3
Connecter et reprendre
Un devis accepté peut préparer une action dans le logiciel de facturation conservé, si son Un point d’échange qui permet à deux logiciels de communiquer. le permet. Un identifiant source stable évite les doublons lors d’une reprise. Les erreurs restent visibles et une personne peut les corriger puis relancer le traitement.
4
Exporter et réceptionner
Exporter les dossiers avec leurs identifiants et statuts, tester les droits et rapprocher le CSV initial des totaux acceptés et rejetés. Le guide remplacer Excel par un logiciel métier fournit un exemple pratique de correspondance des champs.

Périmètre, livraison et reprise de votre outil

Le devis délimite les données à reprendre, les outils conservés, les règles métier et les critères de recette. Un premier lot peut se limiter à un parcours utilisable avant d’étendre le logiciel. Les tâches et exceptions observées pendant le cadrage servent de base à cette décision.

Code prévu au contrat, export des données et documentation d’exploitation font partie de la reprise. Hébergement, formation, maintenance et évolutions sont distingués. Stellary, produit du studio en bêta, illustre les droits d’accès, les objets de travail reliés et les actions IA sous contrôle ; il ne constitue pas une mesure de rentabilité chez un client.

Pourquoi le tableur finit toujours par revenir

Les contournements ne sont pas du désordre : ils décrivent précisément ce que l’outil officiel ne sait pas faire.

Un progiciel impose son modèle. Quand votre métier s’en écarte — et il s’en écarte toujours quelque part — les équipes inventent des contournements : un tableur parallèle, une colonne détournée, un dossier partagé, une convention de nommage que seule une personne connaît.

Ces contournements sont la meilleure spécification qui existe. Ils décrivent exactement ce que l’outil officiel ne sait pas faire, et ce que le métier fait vraiment. Nous commençons toujours par les recenser.

Le but n’est pas de tout remplacer. C’est de construire l’outil web qui manque, connecté à ceux qui fonctionnent déjà, et de supprimer les doubles saisies qui coûtent le plus cher — en temps comme en erreurs.

De l’observation à la mise en production

1
Comprendre
Nous regardons travailler. Les flux réels, les rôles, les cas particuliers, les contraintes réglementaires, les moments où ça coince. Un cadrage sérieux vaut trois mois de développement mal orientés.
2
Prototyper
Des maquettes manipulables sur les écrans qui portent la valeur, avant le code. Une interface se juge en l’utilisant, pas en la décrivant — et un prototype rejeté coûte une semaine, pas un trimestre.
3
Construire
Une architecture explicite : modèle de données défendable, règles métier au bon endroit, Un point d’échange qui permet à deux logiciels de communiquer. documentée, tests sur ce qui casse cher — puis un déploiement observable. L’objectif est qu’un autre développeur puisse reprendre le projet.
4
Déployer et suivre
Mise en production progressive, formation, observation de l’usage. Les six premières semaines révèlent toujours des choses que personne n’avait dites : on les corrige à ce moment-là.

Nos règles de travail

Le périmètre est écrit et négociable ; ce qui est reporté est dit, pas oublié.
Vous voyez tourner quelque chose de réel toutes les deux semaines, pas un rapport d’avancement.
Les données sont modélisées pour durer : c’est ce qui coûte le plus cher à corriger après coup.
La documentation fait partie de la livraison, pas d’une option.
Vous restez propriétaire du code et de la base, et libre de changer de prestataire.

Travail en cours

Voir le travail derrière cette expertise

Des projets en cours pour montrer les choix de produit, de conception et de développement du studio.

Projet en coursStellaryLe poste de commande d’équipes qui livrent avec des agents IA. On décrit un projet, les agents le font avancer sous des règles explicites, et l’humain garde la main sur ce qui compte. En bêta ouverte.Produit, design et développement

Ce qu’on nous demande le plus souvent

Les réponses que nous donnons de toute façon au premier échange.

Comment savoir si le sur-mesure est justifié ?

Trois signaux : vos équipes maintiennent des tableurs pour compenser l’outil officiel, vous payez des licences pour des fonctions que vous n’utilisez pas, ou une règle centrale de votre métier est impossible à exprimer dans le progiciel. Si aucun ne s’applique, restez sur l’existant.

Peut-on reprendre nos données actuelles ?

Oui, c’est même une étape à part entière : extraction, nettoyage, correspondance des modèles, reprise vérifiée. Une migration bâclée fait échouer un projet techniquement réussi.

Que se passe-t-il si nous changeons de prestataire ?

Rien de bloquant, à condition que ce soit prévu dès le départ : code versionné et livré, base standard, Un point d’échange qui permet à deux logiciels de communiquer. documentée, procédure de déploiement écrite. C’est notre mode de travail par défaut.

Travaillez-vous avec nos développeurs internes ?

Oui, fréquemment : en renfort sur une partie du produit, en reprise d’un existant, ou en cadrage et architecture avec exécution interne. Le mode se décide selon vos ressources.