Lexique technique du founder non technique : les mots qu’un prestataire va employer, et les questions à poser derrière

Un founder non technique n’a pas besoin de savoir coder pour piloter un prestataire. Il a besoin de savoir ce que recouvrent une vingtaine de mots qui reviendront dans chaque devis, chaque point d’avancement et chaque incident, et surtout de savoir quoi demander quand il les entend. Un mot technique n’est ni un argument ni une menace : c’est une décision que quelqu’un a prise, ou oublié de prendre, sur votre produit.

Ce lexique est organisé par familles, dans l’ordre où les sujets arrivent dans la vie d’un MVP : ce qui compose le produit, les fondations d’un SaaS, la façon dont le code arrive en ligne, le temps long, puis l’IA. Pour chaque terme, quatre lignes : ce que c’est, pourquoi ça vous concerne, la question à poser, et la réponse qui doit vous alerter. Les questions sont faites pour être posées telles quelles, en entretien ou en point hebdomadaire. Vous n’avez pas à juger la réponse techniquement : vous devez entendre un raisonnement lié à votre produit, pas une habitude de maison.

Ce qui compose le produit

Stack

Définition. L’ensemble des technologies choisies pour construire le produit : langage, framework, base de données, hébergement, services tiers.

Pourquoi vous en soucier. La stack décide de qui pourra reprendre votre produit demain. Une stack répandue (TypeScript, Python, PostgreSQL) se recrute ; une stack rare vous lie au prestataire qui la maîtrise.

La question. « Pourquoi cette stack pour mon produit, et combien de développeurs pourraient le reprendre si nous arrêtions de travailler ensemble ? »

Le signal d’alerte. « C’est ce qu’on utilise toujours », sans lien avec votre projet, ou un framework maison que seule l’agence connaît.

Front et back

Définition. Le front (ou front-end) est ce qui s’affiche dans le navigateur ou l’application mobile ; le back (ou back-end) est la partie qui tourne sur un serveur, applique les règles et parle à la base de données.

Pourquoi vous en soucier. Tout ce qui protège vos données doit être vérifié côté back. Une règle appliquée seulement dans le front se contourne en quelques minutes avec les outils du navigateur.

La question. « Si quelqu’un appelle directement le serveur sans passer par l’interface, qu’est-ce qui l’empêche de voir les données d’un autre client ? »

Le signal d’alerte. « On a masqué le bouton. » Masquer n’est pas interdire.

API

Définition. Une API est le contrat qui permet à deux logiciels d’échanger des données : la liste des demandes possibles et des réponses attendues.

Pourquoi vous en soucier. Votre produit en consomme (paiement, e-mail, IA) et en expose souvent une, ne serait-ce qu’entre son front et son back. Chaque API consommée est une dépendance avec son prix et ses limites ; chaque API exposée est une porte d’entrée à protéger.

La question. « De quelles API externes dépend le produit, que coûtent-elles à l’usage, et que se passe-t-il si l’une d’elles tombe ? »

Le signal d’alerte. Personne ne sait lister les services tiers, ou le coût mensuel des API « dépendra de l’usage » sans aucune estimation.

Base de données

Définition. L’endroit où sont stockées de façon durable les données du produit : comptes, contenus, paiements, historiques.

Pourquoi vous en soucier. Le code se réécrit ; les données de vos clients ne se recréent pas. La structure de la base (le « modèle de données ») est aussi la décision la plus coûteuse à changer après coup.

La question. « Où est hébergée la base, sur quel compte, à quelle fréquence est-elle sauvegardée, et quand avez-vous testé une restauration pour la dernière fois ? »

Le signal d’alerte. « L’hébergeur fait des sauvegardes » sans que personne n’ait jamais restauré. Une sauvegarde jamais restaurée est une hypothèse.

Les fondations d’un SaaS

Multi-tenant

Définition. Une architecture où plusieurs clients (les « tenants », souvent des entreprises) partagent la même application et la même base, chacun ne voyant que ses propres données.

Pourquoi vous en soucier. C’est le modèle de quasiment tous les SaaS B2B, et c’est l’une des rares décisions qui ne se rattrapent pas proprement après le MVP. Une fuite de données entre clients est l’incident qui tue un produit B2B. Nous détaillons pourquoi dans multi-tenant et facturation par abonnement.

La question. « Comment l’isolation entre clients est-elle garantie : par une vérification dans chaque écran, ou par une règle appliquée au niveau de la base ? Et un utilisateur peut-il appartenir à deux organisations ? »

Le signal d’alerte. « On ajoutera la notion d’organisation plus tard. » Plus tard, cela veut dire reprendre chaque table et chaque requête.

Authentification

Définition. Le mécanisme qui vérifie qui est l’utilisateur (connexion, mot de passe, lien magique, connexion Google), à distinguer de l’autorisation, qui décide de ce qu’il a le droit de faire.

Pourquoi vous en soucier. C’est la porte d’entrée de votre produit, et le premier point regardé par un client qui audite ses fournisseurs. La confusion entre authentification et autorisation est l’origine d’une bonne partie des failles.

La question. « Utilisez-vous un service d’authentification éprouvé ou un développement maison ? Et où sont définis les rôles : qui peut inviter, supprimer, exporter ? »

Le signal d’alerte. Un système de mots de passe écrit à la main pour un MVP, ou des rôles qui n’existent que dans l’interface.

RLS (Row Level Security)

Définition. Une fonction de la base de données PostgreSQL qui filtre ligne par ligne ce que chaque utilisateur peut lire ou modifier, selon des règles appelées « politiques ».

Pourquoi vous en soucier. Si votre produit utilise Supabase, ce qui est le cas de la plupart des applications générées par Lovable ou Bolt, la RLS est souvent la seule barrière entre un visiteur et toute votre base. La documentation de Supabase (consultée le 14 octobre 2026) est explicite : une table d’un schéma exposé sans RLS est lisible et modifiable par tout rôle qui a un droit sur elle. Notre check-list de sécurité Lovable et Supabase détaille les vérifications à faire vous-même.

La question. « La RLS est-elle activée sur toutes les tables exposées, et pouvez-vous me montrer un test où un utilisateur essaie de lire les données d’un autre ? »

Le signal d’alerte. « On l’activera avant le lancement », ou des politiques qui autorisent tout le monde « pour que ça marche ».

Comment le code arrive en ligne

Environnements : développement, préproduction, production

Définition. Des copies séparées du produit : le poste du développeur, une préproduction (ou « staging ») qui reproduit la production pour tester, et la production, celle que vos clients utilisent.

Pourquoi vous en soucier. Sans préproduction, chaque modification est testée directement sur vos clients. C’est aussi en préproduction que vous ferez la recette avant de valider une livraison.

La question. « Ai-je accès à une préproduction avec des données de test, et la préproduction utilise-t-elle une base distincte de la production ? »

Le signal d’alerte. Une préproduction branchée sur la base de production, ou « on teste en local, puis on met en ligne ».

CI/CD

Définition. L’intégration continue (CI) lance automatiquement des vérifications à chaque modification du code ; le déploiement continu (CD) met en ligne automatiquement ce qui a passé ces vérifications.

Pourquoi vous en soucier. C’est ce qui permet de livrer souvent sans casser, et de revenir en arrière en quelques minutes quand une version pose problème. Un déploiement fait à la main depuis le poste d’un développeur dépend de cette personne et de sa mémoire.

La question. « Comment une modification arrive-t-elle en production, qui peut le faire, et combien de temps faut-il pour revenir à la version précédente ? »

Le signal d’alerte. « Je déploie depuis mon ordinateur », ou un retour arrière qui suppose de « corriger vite ».

Tests

Définition. Du code qui vérifie automatiquement que le produit fait ce qu’il doit : un calcul (tests unitaires), un parcours complet comme l’inscription ou le paiement (tests de bout en bout).

Pourquoi vous en soucier. Les tests ne prouvent pas que le produit est sans bug ; ils empêchent qu’une modification casse en silence ce qui marchait. Sur un MVP, on n’attend pas une couverture totale, mais les parcours qui rapportent de l’argent doivent être protégés.

La question. « Quels parcours sont couverts par des tests automatiques, et les tests tournent-ils à chaque modification ? »

Le signal d’alerte. Un pourcentage de couverture cité comme une fin en soi, ou « on teste à la main avant chaque livraison ». Pour votre propre vérification à la livraison, voir le cahier de recette du founder.

Supervision

Définition. Les outils qui enregistrent les erreurs et l’état du produit en production, et préviennent quelqu’un quand quelque chose casse.

Pourquoi vous en soucier. Sans supervision, vous apprenez les pannes par vos clients. Avec, l’équipe sait quelle erreur a touché combien d’utilisateurs, et depuis quand.

La question. « Si le paiement échoue pour un client à 23 h, qui est prévenu, comment, et sur quel engagement de délai ? »

Le signal d’alerte. « On regarde les logs quand il y a un souci. »

Le temps long

Dépôt de code et accès

Définition. Le dépôt (sur GitHub, GitLab ou équivalent) contient le code et son historique ; les accès regroupent tous les comptes dont le produit dépend : hébergement, base, nom de domaine, services tiers.

Pourquoi vous en soucier. Posséder le code sur le papier ne sert à rien si le dépôt et les comptes sont au nom du prestataire. C’est ce qui décide si vous pouvez changer d’équipe sans repartir de zéro ; le sujet est développé dans propriété du code et réversibilité.

La question. « Le dépôt et tous les comptes sont-ils créés à mon nom dès le premier jour, avec un accès administrateur pour moi ? »

Le signal d’alerte. « On vous transférera tout à la fin du projet. »

Dette technique

Définition. L’ensemble des raccourcis pris pour aller vite, qui rendent les évolutions suivantes plus lentes ou plus risquées tant qu’ils ne sont pas repris.

Pourquoi vous en soucier. Un MVP sans dette n’existe pas, et ce n’est pas souhaitable. Le problème n’est pas d’en avoir, c’est de ne pas savoir laquelle on a. La distinction entre dette acceptable et dette dangereuse est l’objet de dette technique d’un MVP.

La question. « Quels raccourcis avez-vous pris volontairement, où sont-ils notés, et lesquels faudra-t-il reprendre avant d’avoir cent clients ? »

Le signal d’alerte. « Zéro dette technique. » C’est soit faux, soit le signe qu’on a construit trop lentement.

Refonte

Définition. La réécriture d’une partie importante ou de la totalité du produit, plutôt que son amélioration progressive.

Pourquoi vous en soucier. Une refonte coûte souvent plus que la première version, gèle les nouvelles fonctionnalités pendant des semaines et réintroduit des bugs déjà corrigés. C’est parfois la bonne décision, rarement la première à envisager.

La question. « Qu’est-ce qui empêche concrètement d’améliorer l’existant par étapes, et que gardez-vous de l’actuel ? »

Le signal d’alerte. Une refonte proposée par une nouvelle équipe avant même d’avoir lu le code, ou justifiée uniquement par « ce n’est pas notre stack ».

Scalabilité

Définition. La capacité du produit à supporter plus d’utilisateurs, de données ou de trafic sans dégradation ni réécriture.

Pourquoi vous en soucier. C’est un argument qu’on vous vendra tôt et cher. Un MVP qui n’a pas encore cent utilisateurs a besoin d’un modèle de données correct et d’un hébergement standard, pas d’une architecture conçue pour un million de comptes.

La question. « À quel volume d’utilisateurs l’architecture actuelle commencera-t-elle à poser problème, et que faudra-t-il changer à ce moment-là ? »

Le signal d’alerte. Des microservices, Kubernetes ou plusieurs bases de données proposés pour un premier lancement, sans chiffre de charge à l’appui.

L’IA dans le produit

LLM

Définition. Un grand modèle de langage (GPT, Claude, Gemini, Mistral) : un modèle qui génère du texte à partir d’une consigne, appelé le plus souvent par API chez un fournisseur.

Pourquoi vous en soucier. Sa facture suit l’usage, pas un forfait, et ses réponses ne sont pas déterministes : la même question peut produire deux réponses différentes. Les fournisseurs retirent aussi leurs modèles : chez OpenAI, le retrait de gpt-4.5-preview a été annoncé le 14 avril 2025 pour un arrêt le 14 juillet 2025, selon la page des dépréciations (consultée le 14 octobre 2026).

La question. « Combien coûte un utilisateur actif par mois en appels au modèle, et que se passe-t-il si le fournisseur retire le modèle utilisé ? »

Le signal d’alerte. Aucun chiffre de coût par utilisateur, ou un code où le nom du modèle est écrit en dur à vingt endroits.

RAG

Définition. La génération augmentée par récupération : avant de répondre, le système va chercher dans vos documents les passages pertinents et les donne au modèle comme contexte.

Pourquoi vous en soucier. C’est la façon la plus courante de faire répondre un LLM sur vos propres données, et la qualité dépend d’abord de la recherche, pas du modèle. Le choix entre RAG et entraînement spécifique est traité dans fine-tuning ou RAG.

La question. « Comment mesurez-vous que le système retrouve les bons documents, sur combien de questions réelles ? »

Le signal d’alerte. « On l’a essayé sur quelques questions et ça marche bien. »

Agent

Définition. Un système où le LLM ne se contente pas de répondre mais enchaîne des actions : chercher, appeler un outil, écrire dans une base, envoyer un message.

Pourquoi vous en soucier. Un agent agit en votre nom. Une erreur n’est plus une mauvaise phrase, c’est une mauvaise action : un e-mail envoyé, une donnée supprimée. Sa fiabilité se mesure avant la mise en production, pas en démonstration ; voir construire l’évaluation d’un agent IA.

La question. « Quelles actions l’agent peut-il faire sans validation humaine, et quel taux de réussite avez-vous mesuré sur un jeu de cas réels ? »

Le signal d’alerte. Un agent qui a les mêmes droits qu’un administrateur, ou une fiabilité décrite par « il se trompe rarement ».

Évaluation

Définition. Un jeu de cas de test, avec les réponses ou les comportements attendus, qu’on fait passer au système d’IA à chaque modification pour mesurer sa qualité.

Pourquoi vous en soucier. C’est l’équivalent des tests pour la partie IA. Sans évaluation, changer de consigne ou de modèle revient à espérer que rien ne régresse.

La question. « Combien de cas contient votre jeu d’évaluation, d’où viennent-ils, et quel score faut-il atteindre pour mettre une version en production ? »

Le signal d’alerte. Pas de jeu d’évaluation du tout, ou des cas écrits par l’équipe sans aucune donnée réelle.

Comment se servir de ce lexique

Vous n’avez pas besoin de poser les vingt questions à chaque réunion. Trois usages suffisent.

En entretien, avant de signer. Choisissez cinq questions dans les familles qui concernent votre produit : la stack, le multi-tenant, la RLS si vous partez de Supabase, les environnements et les accès. La façon dont on vous répond compte autant que le contenu : un bon prestataire reformule avec vos mots, cite un compromis et dit ce qu’il ne sait pas encore. Notre grille d’entretien pour choisir une agence MVP va plus loin sur les réponses qui doivent arrêter la discussion.

Pendant le projet. Gardez les questions de la famille « comment le code arrive en ligne » pour les points d’avancement. Elles se vérifient : demandez à voir la préproduction, le dernier déploiement, la liste des tests qui tournent. Un prestataire qui travaille proprement montre tout cela en cinq minutes.

Quand quelque chose casse. Reprenez les signaux d’alerte. Une panne isolée n’est pas une faute ; une panne qui révèle une absence de supervision, de sauvegarde restaurée ou de retour arrière en est une. C’est aussi à ce moment que la question des accès devient décisive : si vous devez changer d’équipe, vous le ferez avec ce qui est à votre nom.

Si vous voulez un regard technique de votre côté de la table sans recruter tout de suite, le CTO externalisé est une option, à condition de savoir lequel des rôles du CTO vous achetez. Et si vous en êtes à choisir l’équipe qui construira le produit, notre façon de travailler est décrite sur la page développement de MVP SaaS ; si votre application a été générée avec Lovable, Bolt ou v0 et que plusieurs réponses de ce lexique vous inquiètent, c’est l’objet de la reprise de projet Lovable.