Les réponses que vous voulez avant de signer.
Choisir une équipe de développement est d'abord une décision de risque, ensuite une décision technique. Cette page explique comment un projet est cadré, comment il est chiffré, ce que vous voyez pendant sa construction, à qui appartient le résultat et ce qui se passe après la mise en ligne. Tout cela est écrit avant le début du développement.
Un projet se déroule toujours de la même façon.
- 01
Cadrage
Nous commençons par une conversation sur ce que le logiciel doit faire et avec quoi il doit fonctionner. Elle ne vous coûte rien et elle aboutit à un périmètre écrit : les fonctionnalités, les systèmes à intégrer, ce qui est explicitement exclu, et des jalons datés. Corriger ce document coûte moins cher que corriger le code.
- 02
Chiffrage
Le chiffrage suit le périmètre, jamais l'inverse. Deux modèles : un prix fixe sur un périmètre écrit quand les besoins sont assez stables pour être figés, ou un forfait mensuel quand les priorités vont continuer de bouger. Nous vous disons lequel convient à votre projet, et pourquoi.
- 03
Réalisation
Le travail avance par sprints, dans vos outils : votre Slack ou Teams, votre outil de tickets, votre dépôt. À la fin de chaque sprint, vous avez une démonstration du logiciel qui tourne plutôt qu'un rapport d'avancement — sur matériel réel lorsqu'il s'agit d'embarqué. Vous parlez aux personnes qui écrivent le code.
- 04
Changements
Les besoins évoluent, c'est normal. Les petits changements sont absorbés dans le sprint en cours par repriorisation, pas en repoussant discrètement la date. Au-delà, vous recevez une estimation écrite du coût et de l'impact sur le calendrier, et vous décidez avant que ce soit construit. Chaque changement accepté est tracé par rapport au périmètre initial.
- 05
Passation
La passation, c'est la documentation, la chaîne de déploiement et une session de transfert avec les personnes qui vont maintenir le système — pas une archive déposée dans votre boîte mail. Le dépôt est le vôtre depuis le premier commit : il n'y a rien à transférer à la fin, les comptes d'hébergement, de cloud et de store sont déjà à votre nom.
- 06
Après la mise en ligne
Les défauts constatés par rapport au périmètre convenu sont à notre charge, pas l'objet d'une nouvelle facture. Ensuite, vous pouvez nous garder pour la maintenance et les évolutions, ou reprendre la documentation et le déploiement en cours avec votre propre équipe. Les deux sont des issues normales.
Ce qui est mis par écrit, à chaque fois.
Le code vous appartient.
La propriété intellectuelle de tout ce que nous produisons vous est transférée. Nous travaillons dès le premier jour dans un dépôt que vous contrôlez, il n'y a aucun framework propriétaire à licencier, et aucune dépendance imposée sur l'hébergement ou la maintenance.
Le périmètre existe avant le travail.
Fonctionnalités, intégrations, exclusions et jalons datés sont écrits et validés avant le début du développement. Un chiffrage sans périmètre derrière lui est une supposition présentée comme un chiffre.
Vous parlez à ceux qui écrivent le code.
Il n'y a pas de commercial entre vous et les développeurs. Une question est traitée par la personne qui va implémenter la réponse.
Une démonstration, pas un rapport.
Chaque sprint se termine par un logiciel que vous pouvez utiliser, sur matériel réel quand le projet est embarqué. Un avancement sur lequel on ne peut pas cliquer n'est pas un avancement.
Un calendrier honnête plutôt qu'un calendrier confortable.
Si une date n'est pas tenable, nous le disons avant le contrat, pas au troisième mois. C'est le périmètre qui décide du délai : nous dimensionnons le travail avant de chiffrer, pas après.
Une journée de travail qui recouvre la vôtre.
Nous sommes à Tunis, en UTC+1. Pour une équipe à Paris, Berlin ou Madrid, c'est la même journée de travail, avec une heure d'écart au maximum pendant l'heure d'été européenne : une question posée le matin trouve sa réponse le matin.
- Fuseau horaire
- UTC+1 à Tunis. La journée de travail se superpose entièrement à celle de l'Europe de l'Ouest, avec une heure d'écart au maximum pendant l'heure d'été européenne.
- Langues
- Anglais, français et arabe. Les réunions, les documents écrits et les revues de code se font dans celle des trois qui convient à votre équipe.
- Outils
- Les vôtres. Nous travaillons dans votre Slack ou Teams, votre outil de tickets et votre dépôt, pour que l'historique du projet reste là où vous pouvez le lire.
- Rythme
- Une démonstration du logiciel qui tourne à la fin de chaque sprint, et le contact quotidien que votre équipe préfère.
Nous développons aussi nos propres logiciels. Dextra, une application web de coaching sportif, est en ligne en arabe, en français et en anglais, avec de vrais utilisateurs et des coachs certifiés.
En savoir plus sur DextraLes questions à poser avant de signer.
- Combien coûte la première conversation ?
- Rien. Nous passons en revue ce que le logiciel doit faire, nous vous disons ce que cela implique selon nous, et nous mettons le résultat par écrit. Si la réponse honnête est que le projet est plus petit que prévu, ou qu'il demande un autre type d'équipe, c'est la réponse que vous recevrez.
- Qu'est-ce qui peut modifier un chiffrage déjà validé ?
- Un changement de périmètre, et uniquement avec votre accord écrit. Nouvelles fonctionnalités, nouvelles intégrations, ou système tiers qui se comporte autrement que sa documentation : tout cela est réestimé en coût et en délai avant d'être construit. Sur un prix fixe, notre propre optimisme n'est pas une raison de rouvrir le chiffre.
- Que voit-on concrètement pendant la construction ?
- Le dépôt, dès le premier commit. L'outil de tickets, puisqu'il est le vôtre. Et une démonstration du logiciel qui tourne à la fin de chaque sprint — sur matériel réel lorsqu'il s'agit d'embarqué.
- À qui appartiennent le code, la propriété intellectuelle et les comptes ?
- À vous. La propriété intellectuelle de tout ce que nous produisons vous est transférée, le dépôt est le vôtre dès le premier commit, et les comptes d'hébergement, de cloud et de store sont ouverts à votre nom au début plutôt que transférés à la fin.
- Que contient la passation ?
- La documentation de la construction et du déploiement du système, la chaîne de build et de déploiement elle-même, et une session de transfert avec l'équipe qui va la maintenir. Rien dans la livraison ne dépend d'un outil que nous serions seuls à pouvoir exécuter.
- Que se passe-t-il si nous arrêtons de travailler ensemble ?
- Vous gardez tout : dépôt, comptes, déploiement, documentation. Il n'y a aucun framework propriétaire à licencier et aucun hébergement que vous ne puissiez déplacer. Mettre fin à la collaboration tient dans un e-mail, ce n'est pas un projet d'extraction.
Commencez par la conversation de cadrage.
Dites-nous ce que le logiciel doit faire. Vous repartez avec un périmètre écrit et un chiffrage, sans engagement de votre côté.
Démarrer un projet