Guides
Vibecoder ses outils plutôt que les acheter
Le calcul a changé. Un outil qui coûtait trois semaines en coûte deux heures — mais tous les abonnements ne valent pas la peine d'être remplacés.
Mis à jour le 21 août 2026 · 5 min de lecture
Une PME suisse accumule facilement quinze abonnements logiciels. Un outil de suivi des congés à onze francs par utilisateur et par mois, un formulaire de contact à trente francs, un tableau de bord à quatre-vingts. Pris un par un, chacun paraît négligeable. Additionnés sur trois ans, on parle de dizaines de milliers de francs pour des fonctionnalités dont on utilise dix pour cent.
Ce calcul était sans appel tant que développer un équivalent coûtait plusieurs semaines. Il ne l'est plus. C'est probablement le changement le plus concret qu'apporte le vibecoding aux petites structures — davantage que l'accélération du développement de produit.
Ce que le calcul est devenu
Le raisonnement classique opposait un coût d'achat prévisible à un coût de développement élevé et incertain. Le second l'emportait rarement. Aujourd'hui, un outil interne à périmètre restreint — un formulaire, un suivi, un tableau de bord alimenté par une base existante — se construit en quelques heures.
Le déplacement ne porte pas sur le coût de construction mais sur le seuil de rentabilité. Un outil qui devait servir cinquante personnes pour se justifier peut désormais se justifier pour trois. C'est ce qui rend pertinent le fait de développer des choses que personne n'aurait envisagé de développer.
Ce qui se remplace bien
Les meilleurs candidats partagent trois traits : un périmètre étroit, des données qui vous appartiennent déjà, et aucune obligation réglementaire particulière.
- Les formulaires et leur suivi — demande de congés, note de frais, réservation de salle. Périmètre stable, règles simples, aucun besoin d'évoluer.
- Les tableaux de bord internes qui agrègent des données déjà en votre possession. L'essentiel du prix d'un outil de visualisation paie une flexibilité dont vous n'avez pas l'usage.
- Les automatisations de tâches répétitives — renommer, convertir, notifier, relancer. C'est le cas d'usage historique du script, désormais accessible sans savoir programmer.
- Les outils métier sans équivalent sur le marché, ceux que vous gérez aujourd'hui dans un tableur partagé à force de ne rien trouver d'adapté.
Ce dernier point mérite l'attention : ce sont ceux qui rapportent le plus. Vous ne remplacez pas un abonnement, vous supprimez un tableur que six personnes s'échangent par e-mail avec trois versions divergentes.
Ce qu'il vaut mieux acheter
La symétrie est nette : dès qu'un outil porte une responsabilité juridique, une obligation de disponibilité ou une complexité qui évolue sans vous, l'abonnement redevient le bon choix.
- La paie et la comptabilité. Les règles changent chaque année et l'erreur se paie en amende. Vous n'achetez pas un logiciel, vous achetez le fait que quelqu'un suive la législation à votre place.
- L'authentification et la gestion des identités. Faire soi-même la gestion de mots de passe est l'exemple type de la fausse économie.
- Le paiement. La conformité aux normes des cartes bancaires n'est pas un sujet qu'on vibecode.
- Tout ce qui doit fonctionner quand vous dormez. Un outil interne qui tombe se répare le lendemain ; un service exposé aux clients, non.
- Tout ce qui manipule des données de santé ou des données sensibles au sens de la nLPD, où le niveau d'exigence dépasse largement le coût de l'abonnement.
Le coût que le calcul oublie
Comparer deux heures de génération à un abonnement mensuel est malhonnête. Un outil interne a un coût de possession que l'abonnement inclut et qu'on oublie systématiquement.
- L'hébergement, modeste mais réel, et le renouvellement des certificats.
- Les mises à jour de sécurité des dépendances, qui n'attendent pas votre disponibilité.
- Les sauvegardes, et surtout leur restauration — une sauvegarde jamais testée n'est pas une sauvegarde.
- Le facteur humain : si une seule personne sait comment l'outil fonctionne et qu'elle part, l'outil part avec elle.
Ce dernier point est le plus sous-estimé dans les petites structures. Il ne se règle pas par de la documentation exhaustive, mais par une note courte expliquant à quoi sert l'outil, où il tourne et comment le redémarrer.
Décider en quatre questions
- Combien coûte l'abonnement sur quatre ans, tous utilisateurs compris ? C'est le seul chiffre à comparer.
- Que se passe-t-il si l'outil est indisponible une journée ? Si la réponse est « pas grand-chose », le développement interne est envisageable.
- Les règles qu'il applique changent-elles sans moi ? Si oui, achetez : vous paieriez cette veille de votre poche.
- Est-ce que quelqu'un d'autre que son auteur pourra le reprendre ? Si non, ce n'est pas une économie, c'est un report de coût.
Une dernière chose : commencez par un outil dont l'échec ne coûte rien. Vous apprendrez le coût réel de possession sur un cas où vous pouvez vous permettre de découvrir que vous l'aviez sous-estimé.
Sur le même sujet
Écrire des prompts qui produisent du code utilisable
Un prompt de code est une spécification. La plupart des mauvais résultats viennent d'une spécification incomplète, pas du modèle.
Sécuriser le code généré par IA
Le code généré est fonctionnel avant d'être sûr. Voici les failles récurrentes, avec les signaux qui permettent de les repérer en relecture.