Il n'y a pas de grille tarifaire, et voici pourquoi.
Nous chiffrons des projets, pas des licences. Ce que coûte un projet découle de ce qu'il doit faire, et c'est différent à chaque fois. Cette page explique ce qui fait varier le montant, la seule fourchette que nous pouvons publier honnêtement, et d'où vient le reste de la réponse. Ce n'est pas une grille de prix.
Une grille tarifaire serait une fiction.
Un logiciel n'est pas un produit en rayon. Deux applications identiques vues de l'extérieur peuvent coûter des sommes très différentes à construire, parce que l'une dialogue avec un prestataire de paiement, un système d'entrepôt et une base de données historique, et l'autre avec rien du tout. Un prix affiché pour « une application mobile » serait juste pour l'une et franchement faux pour l'autre.
Nous ne vendons pas non plus de licences. Il n'y a ici ni prix par utilisateur ni palier d'abonnement, donc rien qu'un tableau de prix pourrait réellement décrire. Ce que nous vendons, c'est un travail cadré, avec un début, une fin et une définition du « terminé » convenue à l'avance.
La plupart des agences règlent la question en ne publiant rien et en vous obligeant à réserver un appel pour apprendre quoi que ce soit. Nous préférons vous dire ce qui fait varier le montant, vous donner la seule fourchette que nous assumons, et dire clairement que le reste sort du cadrage. Si cela vous conduit à conclure que nous ne sommes pas le bon interlocuteur avant même de nous contacter, c'est un bon résultat pour vous comme pour nous.
Ce qui fait réellement varier le montant.
Voici ce que nous regardons pendant le cadrage, à peu près dans l'ordre d'importance. Ce sont pour l'essentiel des décisions, donc pour l'essentiel les vôtres.
- Périmètre
- Le nombre de choses que le logiciel doit faire, et combien d'entre elles sont réellement indispensables au lancement. Le périmètre est le levier le plus puissant de cette liste, et c'est celui que vous maîtrisez entièrement.
- Sur mesure ou standard
- Ce qu'un framework éprouvé ou un module existant fait déjà coûte bien moins cher que ce qu'il faut inventer. Les parties coûteuses d'un développement sont celles qui sont véritablement propres à votre métier — et elles sont en général moins nombreuses que ne le laisse croire la première liste de fonctionnalités.
- Plateformes
- iOS, Android, le web, ou tout à la fois. Une base de code partagée comme Flutter ou React Native évite qu'un développement se transforme en plusieurs, mais chaque plateforme supplémentaire apporte ses propres tests, sa soumission au store et son support.
- Backend et données
- Une interface posée sur une API que vous avez déjà n'est pas le même projet qu'une application qui a besoin de son propre backend : base de données, rôles et permissions, interface d'administration, et un endroit où tout cela tourne.
- Intégrations
- Chaque système externe — prestataire de paiement, ERP, CRM, plateforme logistique, banque, équipement — est une dépendance avec sa documentation, ses cas limites et son propre calendrier. C'est là que les estimations bougent le plus souvent, donc les intégrations sont nommées explicitement dans le périmètre.
- Ambition graphique
- Une interface soignée bâtie sur une bibliothèque de composants standard n'est pas le même travail qu'un design system sur mesure avec animations et illustrations propres. Les deux sont légitimes. Ce n'est pas le même montant.
- Reprise de données
- Sortir les données d'un ancien système est un vrai travail, et il est régulièrement oublié dans les premières conversations. Des données jamais contrôlées, présentes en double ou logées dans des tableurs peuvent coûter plus cher à reprendre que les fonctionnalités qu'elles alimentent ne coûtent à construire.
- Votre degré de certitude
- Un client qui arrive avec des décisions prises obtient un chiffre plus serré qu'un client qui arrive avec une direction. Les deux sont des points de départ acceptables. Ils se chiffrent différemment, et pour une raison honnête : les questions non tranchées finissent par l'être pendant le développement, et c'est l'endroit le plus cher pour les trancher.
Applications et MVP : une fourchette, pas un devis.
C'est le seul chiffre de cette page. Il couvre un seul type de travail — construire une application ou un MVP — et correspond à la plage dans laquelle ces projets se situent.
Les développements d'applications et de MVP commencent généralement à partir de 5 000 TND pour un MVP simple et peuvent aller jusqu'à 50 000+ TND pour des solutions d'entreprise complexes.
À lire comme une fourchette, pas comme un devis. Ce n'est pas un prix attaché à votre projet, et rien n'est chiffré tant qu'il n'y a pas de périmètre écrit. Un périmètre peut placer un développement à l'une ou l'autre extrémité de cette fourchette, et il peut le placer en dehors. Nous la publions parce qu'un repère à confronter à votre budget est plus utile que le silence — pas parce que c'est une offre.
Ce que coûte vraiment une application mobile — le détail (en anglais)Ce sur quoi nous ne mettrons pas de chiffre ici.
Pour le reste de ce que nous faisons, il n'existe pas de fourchette que nous puissions publier honnêtement, et nous n'allons pas en inventer une. Voici ce dont dépend réellement l'estimation. Le montant, lui, sort du cadrage, par écrit, avant que le travail commence.
Sites et applications web
Un site vitrine et une application web partagent un mot et pas grand-chose d'autre. L'estimation dépend du nombre de gabarits de page distincts, du fait que le contenu soit éditable via un CMS et par qui, du nombre de langues, de l'existence de comptes et de permissions derrière, et de la part de design réellement sur mesure plutôt que systématique. Une application multilingue avec des rôles n'est pas le même projet qu'un site vitrine, même quand les deux s'appellent « un site ».
Odoo ERP
Le coût suit la distance entre vos processus et ce qu'Odoo fait déjà. Des modules standard configurés à votre façon de travailler, c'est l'extrémité économique. Les modules sur mesure, la reprise des données du système que vous quittez et l'intégration aux outils que vous gardez, c'est là qu'est le travail. Un point à dire clairement : nous ne sommes pas partenaire Odoo et nous ne revendons pas de licences. Ce que vous payez à Odoo est distinct de ce que vous nous payez, et vous le payez directement.
Automatisation par IA
Le modèle est rarement la partie coûteuse. Ce qui pilote l'estimation, c'est l'état de vos données, le nombre de systèmes que l'automatisation doit atteindre, le degré d'erreur toléré en sortie, et ce qui doit se passer quand la sortie est fausse. Une automatisation que personne ne contrôle coûte moins cher à construire et nettement plus cher à exploiter : le circuit de vérification est donc cadré avec le reste, pas ajouté après coup.
Logiciel embarqué
C'est le matériel qui fixe les règles. L'estimation dépend de la carte et de la chaîne d'outils, du fait qu'un firmware existe déjà ou parte de zéro, des protocoles en jeu, de ce qui doit être certifié, et de la façon dont l'ensemble est testé — parce qu'un travail embarqué se démontre sur du matériel réel, et que ce matériel doit exister avant qu'un calendrier veuille dire quelque chose.
Le périmètre d'abord, le montant ensuite.
- 01
La conversation
Vous nous dites ce que le logiciel doit faire et avec quoi il doit fonctionner. Elle ne vous coûte rien. Si la réponse honnête est que le projet est plus petit que vous ne le pensez, ou qu'il demande un autre type d'équipe, c'est la réponse que vous obtenez.
- 02
Le périmètre écrit
Les fonctionnalités, les systèmes à intégrer, ce qui est explicitement exclu, et des jalons datés. Ce document existe avant tout prix. Une estimation sans périmètre derrière elle est une supposition présentée comme un chiffre.
- 03
Le montant
Alors seulement, un prix. 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, au lieu de retenir par défaut celui qui nous arrange.
- 04
Ce qui peut le modifier
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 un motif de rouvrir le chiffre.
- 05
Comment fonctionnent les demandes de changement
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, si bien qu'à la fin vous pouvez lire ce que vous avez demandé et ce que cela a ajouté.
Dépenser moins sans livrer moins.
Chacun de ces leviers réduit le périmètre, pas la qualité. Réduire la qualité est l'option coûteuse : elle revient sous forme de reprises, et une reprise se paie deux fois.
Livrez la plus petite chose qui prouve l'idée.
Construisez le seul parcours dont l'activité dépend réellement et mettez-le devant de vrais utilisateurs. Une bonne partie de la liste initiale sera réordonnée par ce que vous apprendrez, et une partie sera abandonnée. Payer pour construire ces fonctionnalités d'abord, c'est payer pour l'apprendre plus tard.
Découpez en phases.
Un lancement n'est pas une date limite pour toutes les fonctionnalités que vous voudrez un jour. Convenir de ce qui entre dans la première phase et de ce qui en est délibérément exclu est la décision la moins chère à votre disposition, et elle rend le premier chiffre à la fois plus petit et plus juste.
Servez-vous de ce qui existe déjà.
Une authentification standard, un prestataire de paiement éprouvé, un back-office existant, une bibliothèque de composants. Les versions sur mesure de problèmes déjà résolus sont le coût évitable le plus fréquent d'un développement, et le plus difficile à justifier après coup.
Coupez des plateformes avant de couper des fonctionnalités.
Une plateforme bien faite vaut mieux que deux faites à moitié. Si vos utilisateurs sont sur l'une d'elles, commencez par là et ajoutez l'autre quand le logiciel l'aura mérité.
Apportez des décisions, pas des options.
Toute question laissée ouverte qui arrive jusqu'au développement finit par être tranchée par quelqu'un, et la trancher deux fois coûte plus cher que de la décider une fois. Le contenu, la marque et les règles de votre métier se règlent moins cher avant le développement que pendant.
Ne coupez ni les tests, ni la documentation, ni la maintenance.
Cela ressemble à des économies et n'en est pas. C'est ce qui garde le logiciel peu coûteux à faire évoluer, et le faire évoluer représente l'essentiel de ce que vous en ferez après la mise en ligne.
Les questions que l'on nous pose sur le coût.
- Pourquoi ne pouvez-vous pas simplement donner un prix ?
- Parce qu'un prix sans périmètre derrière lui est une supposition, et qu'une supposition trop basse vous coûte plus cher que pas de chiffre du tout. Dites-nous ce que le logiciel doit faire et vous obtenez un périmètre écrit et un vrai montant en face, sans frais et sans engagement.
- Publiez-vous un tarif journalier ?
- Non. Nous chiffrons un travail cadré, pas des journées. Un tarif journalier vous dit ce que coûte une journée et rien de ce que coûte votre projet, et l'afficher reviendrait à vous inviter à le multiplier par une durée que personne n'a encore estimée.
- La fourchette 5 000 à 50 000+ TND est-elle un devis ?
- Non. C'est la plage dans laquelle se situent les développements d'applications et de MVP, publiée pour que vous puissiez la confronter à votre budget. Votre projet est chiffré à partir de son propre périmètre écrit, et peut se situer n'importe où dans cette fourchette ou en dehors.
- 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 le projet est plus petit que vous ne le pensez, ou s'il demande un autre type d'équipe, c'est ce qu'on vous dira.
- Un prix fixe convenu peut-il changer ?
- Uniquement si le périmètre change, et uniquement avec votre accord écrit. Nouvelles fonctionnalités, nouvelles intégrations ou système tiers au comportement inattendu sont ré-estimés avant toute construction. Notre propre sous-estimation n'est pas un motif de rouvrir un chiffre convenu.
- Le nearshore coûte-t-il moins cher ?
- Cela dépend entièrement de ce que facture une équipe là où vous êtes, comparaison que vous pouvez faire et que nous ne pouvons pas faire à votre place. Ce que nous pouvons énoncer, c'est le dispositif : nous sommes à Tunis, sur UTC+1, la journée de travail recouvre donc celle de l'Europe de l'Ouest de bout en bout, et nous travaillons en anglais, en français et en arabe.
- Qu'est-ce qui n'est pas compris dans le prix d'un développement ?
- Tout ce que vous payez à un tiers : hébergement et cloud, comptes des stores, noms de domaine, licences des logiciels que vous conservez, API payantes. Ces comptes sont ouverts à votre nom dès le départ, vous payez donc les fournisseurs directement et vous voyez exactement ce qu'ils facturent, au lieu de le découvrir à l'intérieur de notre facture.
Obtenez un chiffre qui veut dire quelque chose.
Dites-nous ce que le logiciel doit faire. Vous recevez un périmètre écrit et une estimation en face, sans obligation ni pour l'un ni pour l'autre.
Démarrer un projet