La question se pose toujours dans le même ordre, et c’est le mauvais. On découvre un logiciel qui fait à peu près ce qu’on veut, on souscrit, on découvre les trois points où il ne correspond pas, on paie une option, puis un développement spécifique chez l’éditeur, et au bout de dix-huit mois on se demande si un outil propre n’aurait pas coûté moins cher. Parfois oui, souvent non — et cela se calcule avant, pas après.
Voici les critères qui tranchent réellement, et le calcul à faire une fois pour toutes.
Ce que vous achetez dans un abonnement
Un logiciel en abonnement n’est pas seulement une fonctionnalité : c’est une équipe qui suit les évolutions des modèles, corrige les failles, maintient les intégrations quand les autres éditeurs changent leurs interfaces, et encaisse la charge des pics d’usage. Ce travail est réel et continu. Le reproduire dans un outil propre coûte cher, et c’est le poste que les comparatifs oublient systématiquement.
Ce que vous n’achetez pas : la maîtrise du fonctionnement, la portabilité de vos données, la garantie que le tarif de l’an prochain ressemblera à celui de cette année, et l’assurance que la fonctionnalité dont vous dépendez ne sera pas retirée d’une version à l’autre.
Quatre situations où l’abonnement est le bon choix
- Votre besoin est un besoin standard. Transcrire des réunions, générer des visuels, assister la rédaction : des dizaines d’éditeurs se battent sur ces marchés, et aucun développement spécifique ne rattrapera leur avance fonctionnelle.
- Vous ne savez pas encore ce que vous voulez. Un abonnement mensuel est le prototype le moins cher du marché. Utilisez-le trois mois pour apprendre ce dont vous avez réellement besoin — cette liste ne ressemblera pas à celle du départ.
- Le volume est faible ou irrégulier. Payer à l’usage un outil utilisé vingt fois par mois est imbattable.
- La donnée traitée n’est pas sensible. Si le sujet se limite à des contenus publics ou à des documents sans caractère personnel, l’argument de la confidentialité tombe et avec lui la moitié des raisons de développer.
Trois situations où l’outil propre s’impose
Le processus est votre avantage. Si votre manière de qualifier un dossier, de chiffrer une commande ou d’assembler un produit vous distingue de vos concurrents, la loger dans un outil partagé revient à la ramener à la moyenne du marché. C’est le seul argument vraiment structurant : on ne développe pas pour économiser, on développe pour garder une spécificité.
Les données ne doivent pas sortir. Dossiers de santé, pièces contractuelles, données de clients qui vous l’interdisent par contrat. La question n’est pas la confiance qu’on accorde à l’éditeur mais l’engagement qu’on peut tenir devant son propre client.
Le besoin est un assemblage. Beaucoup de projets ne consistent pas à faire une chose que l’IA fait, mais à relier quatre systèmes internes autour d’une décision. Aucun abonnement ne connaît votre système d’information. Ici l’outil propre n’est pas un choix idéologique, c’est la seule solution qui existe.
Le calcul sur trois ans
Le seul comparatif honnête se fait sur trois ans, et il compte les deux colonnes complètes. Voici les postes que nous voyons oubliés une fois sur deux.
| Poste | Abonnement | Outil propre |
|---|---|---|
| Licence ou développement initial | Coût par utilisateur et par mois, à projeter sur l’effectif de l’année 3 | Conception et développement, une fois |
| Intégration à vos outils | Souvent facturée en supplément, parfois impossible | Comprise dans le projet, c’est même sa raison d’être |
| Usage des modèles | Inclus, mais plafonné : vérifiez le prix au-delà du quota | Facturé à l’usage, quelques dizaines d’euros par mois en général |
| Hébergement et supervision | Inclus | À prévoir, poste récurrent |
| Maintenance corrective et évolutions | Incluse pour le produit, pas pour vos spécificités | Poste annuel à budgéter, sans quoi l’outil se dégrade |
| Sortie | Export des données : vérifiez le format avant de signer | Vous détenez le code et la base |
Deux règles de lecture. L’abonnement est presque toujours moins cher la première année et se renverse à partir du moment où l’effectif ou le volume croît — le point de bascule dépend du tarif par utilisateur, calculez-le plutôt que de le supposer. Et un outil propre sans budget de maintenance annuel n’est pas un investissement : c’est une dette qui commence à courir le jour de la livraison.
La troisième voie, qui est souvent la bonne
Le choix n’est pas binaire. La configuration la plus fréquente chez nos clients combine les deux : des abonnements pour tout ce qui est standard, et un développement propre limité au point où réside la spécificité — le plus souvent une couche de liaison entre les outils du marché et le système d’information interne.
Cette approche a un avantdécisif : elle réduit la surface à maintenir. Vous développez quelques milliers de lignes autour de votre vraie particularité au lieu de reconstruire une interface, une gestion des comptes et un tableau de bord que trois éditeurs proposent déjà.
Le cas particulier des modèles ouverts
Une troisième option existe et change le calcul : faire tourner un modèle ouvert sur une machine que vous louez, plutôt que d’appeler l’interface d’un grand fournisseur. Les modèles ouverts ont atteint un niveau suffisant pour la plupart des usages d’entreprise — classer, extraire, reformuler, répondre à partir de documents fournis.
L’intérêt est double : aucune donnée ne quitte l’infrastructure que vous avez choisie, et le coût devient une location de serveur fixe au lieu d’une facture à l’usage. L’inconvénient est symétrique : vous payez la machine même quand personne ne l’utilise, et la mise à jour du modèle devient votre travail.
La bascule se joue sur le volume et la sensibilité. En dessous de quelques milliers de traitements par jour, l’appel à un fournisseur reste moins cher et moins exigeant. Au-delà, ou dès qu’un engagement contractuel interdit la sortie des données, l’hébergement propre devient raisonnable. Dans les deux cas, faites concevoir l’outil de façon à pouvoir changer de moteur : c’est une question d’architecture, elle se décide au départ et ne coûte presque rien si on y pense à ce moment-là.
Ce que le devis doit faire apparaître
- Le propriétaire du code et le dépôt où il est déposé, nommément.
- Le coût annuel d’exploitation séparé du coût de construction : hébergement, supervision, maintenance corrective, usage des modèles.
- Le moteur utilisé et la façon d’en changer, pour ne pas dépendre d’un fournisseur unique.
- La passation : documentation d’exploitation, accès, et le temps prévu pour transmettre à une autre équipe.
Un devis qui ne distingue pas la construction de l’exploitation cache le poste le plus lourd du projet. Demandez la séparation avant de comparer deux propositions, sinon vous comparez deux choses différentes.
Une question à poser avant de signer, dans les deux cas
Que se passe-t-il si nous arrêtons ? Dans le cas d’un abonnement : sous quel format récupère-t-on les données, en combien de temps, et à quel prix ? Dans le cas d’un développement : qui détient le code, où est-il déposé, et quelle autre équipe serait capable de le reprendre en lisant sa documentation ?
Si l’une de ces réponses est floue, le sujet n’est pas le prix. C’est la réversibilité, et elle se négocie avant la signature — jamais après.
