SaaSChoisir un prestataireContratPropriété du code
Agence de développement SaaS : ce qu'elle doit savoir faire
9 min de lecture
Une agence de développement SaaS doit savoir faire ce qu'une agence d'applications classique ne fait pas : séparer les données de chaque client sur une même plateforme, facturer des abonnements, exploiter le service en continu et organiser la sortie d'un client comme celle de son propre commanditaire. Avant de comparer des devis, une question tranche presque tout : qui sera l'éditeur du logiciel, vous ou l'agence ?
Cet article ne classe aucun prestataire. Il décrit les cinq compétences propres à un SaaS, les questions qui les révèlent en rendez-vous, et ce que le contrat doit en dire. Pour les critères généraux de choix d'une agence (méthode, équipe, prix), notre grille en 12 questions reste la référence.
Pourquoi un SaaS demande des compétences à part
Une application métier sert une entreprise. Un SaaS sert des dizaines ou des centaines d'entreprises sur une même plateforme, qui paient chaque mois et attendent que le service fonctionne quand elles en ont besoin. Trois conséquences changent le métier du prestataire :
- Une erreur touche tout le monde. Un défaut de droits dans une application interne expose des données à un collègue ; dans un SaaS, il peut exposer les données d'un client à un concurrent.
- Le logiciel ne s'arrête jamais. Une mise à jour se déploie pendant que des clients travaillent, et une panne se mesure en clients perdus.
- La relation dure. Le développement de la première version n'est que le début : correctifs, sécurité, évolutions et support continuent tant que le service existe.
Une agence qui a surtout livré des sites vitrines ou des applications internes peut parfaitement apprendre ces sujets. Mais il vaut mieux le savoir avant qu'elle ne les apprenne sur votre produit.
1. Isoler les données de chaque client
C'est la compétence fondatrice. Dans un SaaS, chaque entreprise cliente (un « locataire », tenant en anglais) ne doit jamais voir les données d'une autre. Il existe deux grandes familles d'architecture, que le livre blanc d'AWS sur les stratégies d'isolation des locataires décrit en détail :
| Modèle | Principe | Point fort | Point de vigilance |
|---|---|---|---|
| Mutualisé (pool) | Tous les clients partagent la même base, filtrée | Coûts et mises à jour simplifiés | Un oubli de filtre expose les données d'un autre client |
| Séparé (silo) | Chaque client a ses propres ressources | Isolation forte, exigences clients | Plus d'infrastructure à opérer et à mettre à jour |
| Mixte (bridge) | Mutualisé par défaut, séparé quand il le faut | Souplesse | Deux modèles à maintenir |
Le même document insiste : partager l'infrastructure ne justifie jamais de relâcher l'isolation, au contraire, puisque le risque d'accès croisé augmente. Le sujet n'est pas théorique. Le classement 2025 de l'OWASP, la référence des risques des applications web, place le contrôle d'accès défaillant en première position et indique en avoir trouvé une forme dans 100 % des applications testées. Parmi les exemples cités : consulter le compte d'un autre en changeant simplement son identifiant dans l'adresse.
Ce qu'une agence compétente vous montre : le mécanisme qui limite chaque requête au bon client, appliqué à un seul endroit du code, et les tests automatiques qui vérifient qu'un utilisateur du client A n'obtient rien du client B. Notre article sur l'architecture multi-tenant détaille ces choix.
2. Gérer les abonnements et la facturation
Un SaaS encaisse chaque mois. L'agence doit savoir intégrer un prestataire de paiement, gérer les formules, les essais, les changements de formule en cours de mois, les échecs de paiement et les relances, sans réécrire ce que ces prestataires font déjà. Le bon réflexe est d'intégrer, pas de reconstruire.
Deux sujets sont souvent oubliés :
- Les factures elles-mêmes. En France, la réforme de la facturation électronique impose progressivement des factures structurées entre entreprises. Un SaaS qui facture des entreprises doit s'y préparer.
- Le lien entre l'abonnement et les droits. Quand un client ne paie plus, que se passe-t-il, et à quel moment ? Ce sont des règles métier à décider avec vous, pas des détails techniques.
3. Exploiter le service en continu
Livrer le code ne suffit pas : quelqu'un doit faire tourner le service. Cela recouvre l'hébergement, la supervision (être alerté avant les clients), les sauvegardes testées par une restauration réelle, les mises à jour de sécurité des dépendances, la gestion des incidents et le support de second niveau.
Demandez qui fait quoi, après la mise en ligne, dans chacune de ces lignes. Trois réponses sont possibles, et toutes peuvent convenir :
| Organisation | Ce que cela suppose de votre côté |
|---|---|
| L'agence exploite | Un contrat de service avec engagements écrits |
| Vous exploitez | Une compétence interne ou un autre prestataire |
| Exploitation partagée | Une frontière claire : qui reçoit l'alerte à 3 h du matin |
Une agence qui exploite déjà ses propres services en production sait ce que coûte une nuit d'incident. LPR Studio édite et exploite lui-même deux logiciels en ligne, Izi-Devis et Tubissime : c'est de cette expérience que vient cette liste.
4. Organiser la réversibilité
Un SaaS vit longtemps, et ses prestataires changent. Deux réversibilités sont à prévoir :
- La vôtre vis-à-vis de l'agence. Pouvoir reprendre le produit ou le confier à un autre prestataire : accès au code selon les droits convenus, documentation, scripts de déploiement, comptes d'hébergement à votre nom ou transférables.
- Celle de vos clients vis-à-vis de vous. Un client qui part doit pouvoir récupérer ses données. Le RGPD impose d'ailleurs au sous-traitant, au terme de la prestation et selon le choix du responsable de traitement, de supprimer ou de renvoyer les données personnelles (article 28, paragraphe 3, point g).
Une agence qui conçoit l'export des données dès la première version vous évite une reprise douloureuse plus tard. Le détail des clauses utiles est dans notre article sur la réversibilité et le changement de prestataire.
5. Savoir qui édite le logiciel
C'est la question que beaucoup de fondateurs découvrent trop tard. L'éditeur est celui qui commercialise le logiciel, en porte la responsabilité vis-à-vis des clients et en tire les revenus. Selon le montage, ce peut être vous ou l'agence :
| Montage | Éditeur | Ce qu'il faut vérifier |
|---|---|---|
| Développement commandé au forfait | En principe vous | L'étendue des droits transmis sur le code |
| Développement et exploitation par abonnement | Souvent l'agence | Ce que vous pouvez faire du produit si vous arrêtez |
| Logiciel déjà édité par l'agence | L'agence | Le paramétrage possible et la portabilité de vos données |
Aucun montage n'est meilleur par principe. Un fondateur qui veut lever des fonds ou revendre sa société aura besoin de démontrer ses droits sur le produit ; une PME qui veut surtout un outil qui marche peut préférer ne pas porter l'exploitation. Dans tous les cas, les droits de chaque partie sont définis au cas par cas dans le contrat. Notre article à qui appartient le code source explique la distinction entre cession et licence, et les clauses d'un contrat de développement liste ce qu'il faut relire.
Les questions à poser en rendez-vous
| Question | Une bonne réponse | Un signal d'alerte |
|---|---|---|
| Comment une requête est-elle limitée aux données d'un client ? | Un mécanisme central, testé automatiquement | « On fait attention » |
| Quels SaaS exploitez-vous aujourd'hui en production ? | Des services en ligne, consultables | Uniquement des sites ou des maquettes |
| Qui reçoit les alertes après la mise en ligne ? | Un nom, une procédure, des engagements écrits | « Vous nous appelez si ça ne marche pas » |
| Comment un client de mon SaaS récupère-t-il ses données ? | Un export prévu dès la V1 | « On verra le moment venu » |
| Qui sera l'éditeur, et quels droits aurai-je sur le code ? | Une réponse écrite, liée à la formule choisie | Une réponse orale, vague ou évasive |
| Que me montrez-vous avant que je m'engage ? | Un prototype ou une démonstration concrète | Un devis seul, sans rien à voir |
Ce qu'une agence ne fera pas à votre place
Même la meilleure agence ne sait pas si des entreprises paieront pour votre produit. Valider le besoin, fixer le prix, vendre et décider des priorités restent votre travail. Si vous cherchez quelqu'un pour porter aussi les décisions techniques à vos côtés, la question devient celle d'un CTO, que nous comparons au studio dans CTO externalisé, à temps partagé ou studio.
Comment LPR Studio se situe
LPR Studio est un studio d'édition logicielle à Rennes. Nous commençons par un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : vous voyez le parcours principal de votre SaaS avant tout engagement. Ensuite, trois formules : l'édition SaaS (un logiciel que nous éditons et exploitons), l'abonnement (nous développons et exploitons votre application sans que vous payiez le développement, et nous restons éditeur) et le forfait à prix fixe. Nous ne vendons ni heures ni personnel. Les formules sont décrites sur la page des offres.
Nous ne sommes pas le bon choix pour tout le monde : si vous voulez construire une équipe technique interne dès le premier jour, ou si votre produit est avant tout un sujet de recherche, un recrutement ou un associé technique vous servira mieux qu'un studio.