Questions fréquentes

Non, pas directement. Le quote builder est un outil de cadrage : il capture le brief de ton projet en 5 minutes environ (aucun prix affiché). Ensuite on prend un court appel ensemble où Oussema te partage l'estimation sur mesure basée sur ce que tu as soumis. Comme ça le chiffre reste précis, pas un montant approximatif sorti d'un formulaire.

Chaque projet est différent, les tarifs sont donc personnalisés. Le flow est simple : tu remplis le quote builder (environ 5 minutes) pour cadrer ton besoin, on prend un court appel ensemble, et je t'envoie une estimation sur mesure juste après. Sans engagement, sans frais cachés.

Un devis se construit autour de trois facteurs : le périmètre du projet (fonctionnalités et pages), la complexité technique (IA, automatisations, backend custom) et le délai. Le quote builder capture tout ça en amont, ensuite on en discute ensemble lors d'un court appel avant de partager l'estimation finale.

Le paiement se fait par jalons, généralement un acompte au démarrage puis des paiements à chaque livraison majeure. Virements bancaires et la plupart des méthodes de paiement internationales acceptés. Le calendrier complet est défini avant tout démarrage.

Oui, les projets démarrent avec un acompte (généralement entre 30 et 40 pour cent du total). Il réserve ton créneau dans le planning et couvre la phase de kickoff. Le solde se paye par jalons au fil du projet.

Non. Le devis couvre tout ce qu'on a défini ensemble. Si quelque chose hors périmètre se présente plus tard (nouvelles fonctionnalités, intégrations supplémentaires), on en discute et on chiffre séparément avant toute action. Pas de mauvaise surprise.

Trois. Le prix fixe pour un périmètre défini avec des livrables clairs, c'est le cas de la plupart des projets car le budget reste prévisible des deux côtés. Le forfait mensuel pour la maintenance, le support ou le conseil dans la durée. La régie quand le périmètre est vraiment ouvert et que tu veux piloter sprint par sprint. Dans tous les cas, le devis est écrit et validé avant le moindre travail.

Par le biais d'un bon de commande écrit, avant le début de tout nouveau travail. Je documente la nouvelle exigence, j'estime son impact sur le calendrier et j'envoie un prix révisé en USD. Vous l'approuvez ou non, et le périmètre convenu se poursuit dans les deux cas. Rien n'est développé sur une simple demande orale pour être facturé comme une surprise à la fin, ce qui est la cause la plus fréquente d'un projet à prix fixe qui tourne mal.

Cela tient à quatre choses : combien de questions il doit traiter de façon fiable, où vivent les réponses (un corpus propre va vite, cinq outils éparpillés beaucoup moins), quels systèmes il doit atteindre (CRM, WhatsApp, données de commandes) et s'il lui faut un jeu d'évaluation et une revue de sécurité avant la mise en ligne. Décris le bot dans le quote builder, environ cinq minutes, et tu reçois un devis écrit après un court appel plutôt qu'un chiffre qui ignore ton contexte.

Un projet cadré, par exemple un chatbot qui répond à partir de tes documents ou un workflow automatisé, prend généralement quatre à huit semaines. Un agent en production qui touche plusieurs systèmes internes demande trois à six mois, surtout consacrés à l'accès aux données, à l'intégration et aux tests. Un MVP resserré peut sortir en deux semaines. La date exacte sort de l'appel de cadrage, car ce qui pèse vraiment, c'est l'accessibilité de tes données.

Dès que le devis est validé et l'acompte reçu. Si mon planning est chargé, je te préviens dès le départ pour qu'on cale ensemble une date de démarrage réaliste. On ne démarre jamais sans que tu aies visibilité totale sur le calendrier.

Oui, quand mon planning le permet. Un projet en mode urgence implique un rythme quotidien plus intense et un léger surcoût (rush fee) en plus du devis standard. Le mieux est de mentionner la deadline dès le départ pour que je confirme la faisabilité.

Une intégration ciblée, comme un chatbot répondant à partir de vos documents ou un seul workflow automatisé par un agent ADK ou Genkit, prend généralement de quatre à huit semaines. Un agent en production qui interagit avec plusieurs systèmes internes nécessite trois à six mois, et la majeure partie de ce temps est consacrée à l'accès aux données, à l'intégration et aux tests, plutôt qu'au travail sur le modèle. Ce qui fait vraiment varier les délais, c'est l'accessibilité de vos données : si le contenu est réuni dans un seul endroit propre, la construction peut débuter dès la première semaine, tandis que s'il est dispersé dans cinq outils, la phase de découverte s'allonge en conséquence.

Oui, si le périmètre reste restreint. Deux semaines permettent de résoudre un problème clair, d'utiliser une source de données et des modèles existants plutôt qu'un entraînement complet, le tout sur une stack déjà en production (Next.js, Firebase, Genkit). C'est suffisant pour présenter un produit fonctionnel à de vrais utilisateurs et déterminer s'il mérite d'être développé plus sérieusement. Ce n'est pas suffisant pour une facturation multi-tenant, un back-office complet ou une revue de conformité, et je vous en informerai avant d'accepter l'échéance plutôt qu'après.

Quatre étapes : kickoff (on aligne objectifs, périmètre et direction design), build (sprints itératifs avec previews régulières), review (tu testes, tu donnes du feedback, on polit) et launch (déploiement, formation si besoin, remise des clés). Tu as une visibilité à chaque étape.

Par défaut on utilise un canal partagé (WhatsApp, Slack ou email, au choix) pour les messages quotidiens et un point hebdomadaire d'environ 30 minutes pour faire le tour des avancées et des décisions. Asynchrone d'abord, appels quand c'est utile.

Les révisions sont intégrées au process : à chaque sprint ou jalon tu donnes ton feedback et on itère jusqu'à ce que le livrable corresponde à ce qu'on avait défini. Pas de plafond artificiel. Les changements de périmètre majeurs (nouvelles fonctionnalités, réorientation) sont chiffrés à part.

En principe ça n'arrive pas parce que tu vois et tu valides à chaque étape (design, build, finition). Si quelque chose ne va pas, on l'identifie tôt et on ajuste. Le process itératif évite la grande révélation finale du tout ou rien.

Dans ce cas, je travaille sous la direction de votre CTO, pas à sa place. Un CTO possède généralement la vision de l'architecture et le contexte produit, mais dispose d'un nombre d'heures limité, en plus de lacunes spécifiques qui se situent souvent au niveau de l'AI et de l'automatisation. Je prends en charge un périmètre bien défini (un agent, un pipeline de données, une intégration, une intervention d'urgence) et je le livre au sein de votre dépôt existant, en respectant vos conventions de branche et votre processus de revue de code. Votre CTO conserve la maîtrise et la supervision technique, et les délais sont tenus.

Faire appel à VAIIBE est judicieux quand le système doit être livré immédiatement et que vous ne pouvez pas consacrer trois à six mois au recrutement, à l'intégration et au paiement d'un salaire à temps plein avant la première version. Vous obtenez un ingénieur senior qui maîtrise déjà la stack en production (Next.js, Firebase, Google ADK, Genkit, LangChain, LangGraph, n8n) et qui gère l'architecture, la construction et le déploiement sans transition au milieu du projet. Une embauche en interne est préférable une fois que le produit est stable et que le travail se résume à la maintenance continue d'un système que vous possédez déjà.

Cinq domaines. Des SaaS sur mesure ainsi que des applications web et mobiles basées sur Next.js et Firebase. Des agents AI et chatbots conçus avec Firebase Genkit et Google ADK, incluant la recherche sur vos propres documents. De l'automatisation sur mesure avec des agents AI sur Google ADK, Genkit, LangChain et LangGraph, du transfert de données entre applications aux workflows autonomes, avec n8n quand un outil low code convient mieux. Du e-commerce et des marketplaces. Enfin, du conseil : audits SEO et GEO, reprise de bases de code générées par AI, et mentorat technique.

Oui. Le cross-platform (React Native ou Flutter) est l'option par défaut parce que c'est plus rapide et que ça couvre les deux stores. Le natif reste possible si le projet l'exige vraiment. La meilleure approche est discutée ensemble lors de l'appel de cadrage.

Oui, l'intégration IA est un service clé. Cas typiques : chatbot entraîné sur tes données, génération de contenu ou de documents, recherche et recommandations, automatisation de tâches répétitives. On commence par un audit rapide pour identifier où l'IA apporte de la vraie valeur, pas juste du buzz.

Principalement Next.js et React côté frontend, Node et Firebase ou backends customs côté serveur, Tailwind pour le style, et des outils comme Genkit ou OpenAI pour la partie IA. Le choix de la stack est toujours guidé par ce qui sert le mieux ton projet, pas par la mode.

Google ADK, Genkit, LangChain et LangGraph, choisis projet par projet plutôt que par habitude. Genkit gère l'orchestration des modèles, les sorties structurées et l'évaluation dans une application TypeScript. ADK porte les agents qui ont besoin d'outils, de mémoire et d'une boucle longue. LangGraph convient aux workflows ramifiés qui conservent un état. n8n reste la colle simple entre outils SaaS existants. Le choix est écrit noir sur blanc pendant le cadrage, pour que tu saches ce qui fait tourner ton produit et pourquoi.

Le modèle qui convient à la tâche et au budget, pas un favori unique. La plupart des flux en production tournent sur un petit modèle rapide : la réponse arrive en une seconde environ et la facture mensuelle reste basse. Le raisonnement lourd ou les documents longs passent à une gamme supérieure uniquement quand le gain de qualité se voit dans le jeu d'évaluation. Le fournisseur est isolé derrière une seule interface dans le code : changer de modèle est un réglage, pas une réécriture.

Oui, et le code est écrit pour ça dès le premier jour. Les appels au modèle passent par un seul adaptateur, les prompts et les jeux d'évaluation vivent dans ton dépôt, et rien de spécifique à un fournisseur ne se glisse dans la logique métier. Changer revient alors à modifier un réglage puis à relancer le jeu d'évaluation pour vérifier que la qualité tient. Les prix et la qualité des modèles bougent tous les quelques mois : rester prisonnier d'un fournisseur, c'est ainsi qu'une fonctionnalité qui marche devient coûteuse.

Oui. Les projets tournent sur Google Cloud et Firebase, où la région de la base et du stockage est fixée à la création, donc tes données peuvent rester dans l'Union européenne, aux États-Unis ou dans une autre région supportée. L'hébergement est facturé par Google sur ton propre compte : tu gardes le contrôle et tu peux tout emporter. Si tu préfères héberger ailleurs, la stack repose sur Next.js et des conteneurs standards, donc elle se déplace.

Je maintiens une séparation stricte entre mes environnements de développement et vos systèmes de production. Les données sont chiffrées en transit et au repos avec des protocoles standard comme AES 256, et l'accès suit un modèle de zero trust où chaque requête est authentifiée et autorisée. Comme je suis le seul ingénieur à concevoir et à exploiter votre projet, la liste des personnes ayant accès à vos données se limite à mon seul nom, et je vérifie systématiquement les accès, les secrets et les dépendances avant chaque mise en production.

Là où votre régulateur et vos utilisateurs l'exigent. Mes projets fonctionnent sur Google Cloud et Firebase, où la région de la base de données et du stockage est fixée lors de la création. Les données peuvent donc rester au sein de l'Union européenne, aux États-Unis ou dans une autre région prise en charge. Je vous fournis la liste précise des régions et des services lors de la livraison, afin qu'un responsable de la conformité puisse cartographier les flux de données sans avoir à me solliciter. Si la résidence des données est une contrainte forte, elle doit être décidée lors du premier appel de cadrage, car déplacer une base de données Firestore en production entre différentes régions est coûteux.

Oui. Tout projet traitant des données personnelles au sein de l'Union européenne est conçu pour respecter les droits RGPD qui comptent en pratique : accès, rectification, effacement et portabilité. Je signe un accord de traitement des données vous désignant comme responsable du traitement et moi-même comme sous-traitant. Je documente ce qui est stocké et où, et je liste chaque sous-traitant tiers (hébergement, fournisseurs de modèles, email, analytique) afin que votre propre dossier de conformité reste précis, sans avoir à deviner la composition de la stack.

Oui, régulièrement, et avant que vous ne partagiez quoi que ce soit de sensible. Un bon accord de confidentialité couvre à la fois la phase de développement et la période suivant la livraison. Assurez-vous qu'il mentionne les données, les prompts et la logique métier, et pas seulement le code source, car sur un projet d'AI, les prompts et le jeu d'évaluation constituent souvent un avantage concurrentiel plus important que le code lui-même. Envoyez-moi le vôtre et je le signerai, ou demandez-le-moi et je vous enverrai un modèle mutuel standard.

À vous. Chaque contrat que je signe cède le code source, la documentation et l'architecture à votre entreprise dès le paiement, et le dépôt réside dans votre organisation dès le premier commit plutôt que dans la mienne. Plus généralement, la propriété dépend entièrement du contrat signé avant le début du travail : lorsqu'un accord est silencieux sur la cession de propriété intellectuelle, le développeur peut conserver le code sous-jacent et ne vous accorder qu'une licence limitée. Insistez sur une clause explicite transférant les droits d'auteur, les brevets et les secrets commerciaux à votre entreprise, quel que soit le prestataire que vous finissez par embaucher.

Chaque lancement est accompagné d'une garantie de 30 jours couvrant tout ce qui ne se comporte pas comme convenu, sans frais supplémentaires. Par la suite, un plan de maintenance mensuel couvre le suivi de la disponibilité et des erreurs, les mises à jour des dépendances et de sécurité, les changements d'API et de modèles côté fournisseur, ainsi que les petites évolutions. Pour les fonctionnalités d'AI, je surveille également la qualité des réponses et la latence plutôt que la seule santé du serveur, car un chatbot peut être parfaitement disponible tout en se trompant avec assurance.

Oui, et elle reste optionnelle. Chaque mise en ligne inclut 30 jours de garantie sur tout ce qui ne se comporte pas comme convenu. Ensuite tu peux prendre un forfait mensuel couvrant la supervision de la disponibilité et des erreurs, les mises à jour de dépendances et de sécurité, les changements de modèles côté fournisseur et les petites évolutions, ou payer à l'intervention. Les coûts de fonctionnement comme l'hébergement et l'usage des modèles sont séparés et restent sur tes comptes : le produit peut donc rester en ligne sans aucun forfait.

Les bugs liés à ce qu'on a construit sont corrigés gratuitement pendant la période de garantie (généralement 30 jours après le launch). Au-delà, les correctifs sont pris en charge par le forfait maintenance ou facturés à l'intervention. Dans tous les cas, je réponds vite.

Oui. Chaque projet inclut 30 jours de garantie à partir du launch. Tout ce qui ne fonctionne pas comme on l'avait défini est corrigé sans frais pendant cette période. Au-delà, les forfaits maintenance prennent le relais.

Oui. Les petites modifications et corrections sont couvertes par le forfait de maintenance mensuel, ce qui représente la solution la plus économique pour faire évoluer un produit en production. Tout changement modifiant l'architecture, ajoutant une intégration ou altérant le comportement d'une fonctionnalité AI est défini comme un petit projet à prix fixe, afin que tu connaisses le coût d'une modification avant de commencer. Pour les fonctionnalités AI, je relance le jeu d'évaluation après chaque modification de prompt ou de modèle, car un changement qui semble anodin peut discrètement faire chuter la précision dans la mauvaise direction.

Trois lignes, facturées par les fournisseurs directement sur tes comptes et non via moi : l'hébergement, qui reste bas car la stack descend à zéro quand personne ne l'utilise ; l'usage des modèles, qui suit le nombre de conversations et la longueur de chaque réponse ; et le stockage de tes données et fichiers. Je dimensionne tout ça avec toi avant la construction et je choisis le plus petit modèle partout où il fait le travail, pour que le coût de fonctionnement reste proportionnel à l'usage réel au lieu de tomber comme une surprise mensuelle.

Je suis basé en Tunisie, mais je travaille à distance avec des clients en Europe, en Afrique du Nord et au Moyen-Orient. Le fuseau horaire avec l'Europe permet une collaboration quotidienne fluide.

Trois langues de travail : anglais, français et arabe (Darija tunisienne incluse). La documentation projet, les appels et les livrables peuvent être dans l'une de ces langues, ou mélangés si ton équipe est multilingue.

100 pour cent à distance par défaut, c'est comme ça que tous mes projets tournent aujourd'hui. Des déplacements sur site restent possibles en Tunisie ou en Europe pour un kickoff ou un workshop, frais de déplacement à la charge du client.

Je travaille avec des clients en Tunisie, dans la région MENA, en Europe et aux États-Unis. Étant basé en Tunisie, ma journée de travail coïncide presque entièrement avec les horaires de bureau européens et couvre une bonne partie de la matinée américaine. Les projets sont réalisés en anglais, en français ou en arabe, selon votre préférence. La livraison se fait par défaut à distance. Ce qui compte réellement, c'est donc la compatibilité des fuseaux horaires et la langue dans laquelle vous souhaitez travailler, pas la distance géographique.