Logiciel interne ou SaaS : comprendre la différence avant de développer

Les termes logiciel interne et SaaS sont souvent présentés comme des options concurrentes. Ils répondent pourtant à deux questions différentes : l'un dit qui utilise l'outil, l'autre dit comment il est fourni. Les confondre conduit à des devis mal calibrés. Cet article propose une grille simple pour situer votre projet avant de développer.

Préciser l'usage et le mode de fourniture

Un outil métier récent relie des usages d'équipe et des profils autorisés au sein d'une application hébergée. Une évolution de ses échanges avec une boutique a fait l'objet d'une étude séparée, avant développement : elle n'est pas devenue un nouveau service commercial lancé.

Pour cadrer un projet de logiciel, précisez donc les utilisateurs, les responsabilités d'exploitation et le périmètre de chaque évolution. Un service SaaS peut aussi servir une équipe interne : l'usage ne définit pas à lui seul le mode de fourniture ni les responsabilités. Le mode hébergé seul ne prouve pas l'existence d'une offre SaaS commercialisée.

Deux questions à ne pas mélanger

La première question porte sur l'usage : qui se sert du logiciel ? Votre équipe, vos partenaires, vos clients ou le grand public. La seconde porte sur le mode de fourniture : le logiciel est-il développé et exploité pour vous, ou consommé comme un service proposé par un fournisseur ?

Le NIST, organisme américain de normalisation, décrit le Software as a Service comme l'usage d'applications d'un fournisseur, exécutées sur une infrastructure cloud et accessibles notamment par navigateur ou par API, sans que le client administre cette infrastructure. Cette définition décrit une manière de fournir un logiciel, pas un public : un outil réservé à vos salariés peut très bien être consommé en SaaS.

À l'inverse, héberger une application sur mesure ne suffit pas à définir une offre SaaS commerciale. Si vous souhaitez proposer ce logiciel à d'autres organisations, il faudra aussi cadrer les accès, le support, les conditions d'utilisation et le modèle économique selon votre projet.

Une matrice pour situer votre projet

Croisez l'usage et la fourniture : chaque case appelle un cadrage différent.

La ligne du haut concerne surtout l'organisation du travail. Celle du bas ajoute l'accompagnement d'utilisateurs extérieurs et, pour une offre ouverte, un modèle commercial à construire. Un projet peut aussi changer de case : un outil interne peut évoluer vers un service proposé à d'autres organisations, ce qui modifie le cadrage.

Trois exemples fictifs

Ces situations sont inventées et ne correspondent à aucune entreprise réelle.

• Atelier de menuiserie. Il suit ses commandes dans un outil conçu pour ses étapes de fabrication : usage interne, application sur mesure. Le choix se décide après comparaison des services existants, des adaptations nécessaires et du coût global d'exploitation.
• Cabinet de conseil. Il planifie ses missions avec un service en ligne existant : usage interne, fourniture SaaS. Il n'y a rien à développer, mais il faut vérifier l'export des données.
• Réseau de loueurs de matériel. Il veut proposer un outil de réservation à ses adhérents : usage externe. Si l'outil est fourni à ces structures comme un service en ligne, il peut prendre la forme d'une offre SaaS. Les accès, la séparation des données et le support sont alors à cadrer.

Exploitation : ce qui commence après la livraison

Mettre un logiciel en ligne n'est que le début. Quelqu'un doit ensuite répondre à des questions concrètes.

• Qui crée les comptes et attribue les rôles : création, validation, consultation, administration ?
• Qui surveille le fonctionnement et traite les incidents ?
• Où sont hébergées les données, et qui vérifie que les sauvegardes sont restaurables ?
• Qui applique les mises à jour de sécurité et fait évoluer l'outil ?

Pour un outil interne, ces tâches peuvent reposer sur une personne désignée dans l'équipe, avec un prestataire en appui. Pour une offre destinée à des clients, elles deviennent un engagement envers des tiers. Le niveau d'exigence dépend des données traitées : il se décide au cas par cas et se consigne par écrit. Si votre projet va vers une offre ouverte, la page sur le développement SaaS à Annecy détaille cette approche.

Réversibilité : penser à la sortie dès le départ

Que vous achetiez un service ou fassiez développer un outil, demandez-vous comment en sortir avant d'y entrer.

• Export : vos données sont-elles récupérables dans un format lisible ?
• Propriété : à qui appartiennent le code, les données et les comptes d'hébergement ?
• Documentation : un autre prestataire pourrait-il reprendre le projet ?
• Dépendances : quels services tiers sont indispensables, et sous quel contrat ?
• Fin de relation : que deviennent vos données, et dans quel délai ?

Ces réponses pèsent autant que le prix initial. Un logiciel sur mesure sans documentation peut enfermer autant qu'un service dont on ne peut rien exporter.

Checklist avant de demander un devis

Répondez à ces questions par écrit, même brièvement.

• Besoin : quel problème précis doit être résolu, et pour qui ?
• Marché : un service existant couvre-t-il l'essentiel ? Si oui, testez-le d'abord.
• Utilisateurs : internes, partenaires ou clients, avec quels rôles ?
• Première version : quel périmètre minimal serait déjà utile ?
• Exploitation : qui administre et qui répond aux utilisateurs ?
• Sortie : comment récupérer les données si vous changez d'outil ?

Pour avancer, rassemblez ces réponses sur une page : je vous propose de partir de là pour définir un prototype et une première version, l'hébergement et la maintenance étant cadrés par écrit, sur devis. Vous pouvez commencer par la page application web et outils métier, puis me contacter via la page contact.

Dernière mise à jour : 20 octobre 2026.
← Tous les articles