Bubble triple ses tarifs, votre client trinque : le risque que vous ne possédez pas

C'est la grande force du no-code, et son angle mort. Vous livrez vite, sans serveur à administrer, sans code à maintenir ligne à ligne. Mais cette vitesse a une contrepartie que beaucoup de clients ignorent : l'application que vous livrez ne tient debout que parce qu'une plateforme tierce la fait tourner. Bubble héberge la logique, Airtable stocke les données, Make ou Zapier orchestrent les automatisations. Vous assemblez des briques que vous ne possédez pas.

Tant que ces plateformes restent stables, tout va bien. Le problème, c'est qu'elles évoluent en permanence, et pour des raisons qui vous échappent totalement : leur modèle économique, leur stratégie produit, un rachat, une levée de fonds qui change les priorités. Du jour au lendemain, sans que vous touchiez à quoi que ce soit, l'application livrée peut devenir plus chère, dégradée, ou carrément cassée.

Les scénarios ne sont pas théoriques, ils sont la réalité du secteur :

• Une plateforme multiplie ses tarifs ou change sa grille (passage au nombre d'enregistrements, aux exécutions de scénarios, aux utilisateurs actifs).
• Une fonction est dépréciée ou une intégration tierce supprimée, et le workflow s'arrête.
• Un connecteur change son API, et l'automatisation que vous aviez branchée renvoie des erreurs.
• Une plateforme est rachetée, puis sa feuille de route réorientée ou son offre gratuite supprimée.
• Plus rare mais brutal : un service ferme et donne quelques mois pour migrer.

Dans tous ces cas, il n'y a aucune faute de "code" de votre part. L'application que vous avez assemblée était correcte. Et pourtant, c'est vous que le client va appeler.

Du point de vue du client, la distinction entre "votre prestation" et "l'outil que vous avez choisi" n'existe pas. Vous êtes son interlocuteur, son prestataire, celui qui a recommandé Bubble plutôt qu'un développement classique, Airtable plutôt qu'une base de données dédiée. Quand le sol se dérobe, c'est vers vous qu'il se tourne, pas vers un éditeur américain injoignable.

Et l'argument juridique qu'il invoque n'est pas "votre code est buggé" : c'est votre devoir de conseil. Concrètement, on peut vous reprocher :

• De ne pas l'avoir averti de la dépendance à une plateforme tierce et de ses conséquences.
• D'avoir choisi un outil inadapté à son volume, sa criticité ou son budget de fonctionnement.
• De ne pas l'avoir prévenu du coût récurrent qui allait grimper avec la croissance de son activité.
• D'avoir créé une situation de verrouillage (lock-in) dont il ne peut sortir sans tout reconstruire.

Le no-codeur n'est pas responsable de la décision tarifaire d'un éditeur. Mais il peut l'être de ne pas avoir éclairé son client sur le risque qu'une telle décision faisait courir au projet. La faute reprochée se déplace du "comment" technique vers le "quoi" du conseil.

C'est un préjudice typiquement immatériel : aucun dommage physique, mais un surcoût d'abonnement, une migration forcée, une perte d'exploitation pendant que l'application ne tourne plus. La RC Professionnelle couvre précisément ces dommages immatériels causés au client par un manquement au devoir de conseil ou une erreur d'appréciation dans la prestation.

Toute hausse de prix d'une plateforme ne vous est évidemment pas imputable. La question décisive est de savoir si vous avez agi en professionnel diligent, ou si vous avez laissé le client dans l'ignorance d'un risque que vous, vous connaissiez.

Penchent vers une faute qui vous est opposable :

• Aucune mention écrite de la dépendance aux plateformes ni de leurs conditions tarifaires.
• Un choix d'outil manifestement disproportionné (plateforme grand public pour un usage critique à fort volume).
• Une promesse de coût annoncée comme stable alors qu'elle dépend d'abonnements tiers variables.
• L'absence totale de stratégie de sortie ou de sauvegarde des données du client.

Relèvent plutôt de l'aléa, difficile à vous reprocher :

• Une décision tarifaire imprévisible de l'éditeur, prise après votre livraison et que rien ne laissait présager.
• Une fermeture soudaine d'un service, dès lors que vous aviez documenté la dépendance et prévu la portabilité.
• Un client qui a refusé par écrit une alternative plus robuste que vous aviez proposée.

On retrouve la même logique que pour n'importe quelle prestation intellectuelle : ce qui vous protège, ce n'est pas l'absence de problème, c'est la trace écrite que vous avez éclairé le client. Un e-mail, une clause, une note d'architecture peuvent faire toute la différence entre une faute caractérisée et un risque assumé en connaissance de cause par le client.

La meilleure parade à ce risque structurel tient en un document simple que trop peu de no-codeurs produisent : une matrice de dépendances. L'idée est de cartographier, dès la conception, de quoi dépend l'application livrée, et d'en informer formellement le client.

Concrètement, pour chaque projet, listez :

Ce document a une double vertu. Côté commercial, il vous positionne comme un professionnel sérieux qui ne vend pas une boîte noire. Côté juridique, il est exactement la pièce qui démontre que vous avez rempli votre devoir de conseil : le client savait, il a choisi en connaissance de cause. En cas de litige, c'est ce qui sépare l'erreur du prestataire de la décision malheureuse d'un éditeur.

Au-delà de la matrice, trois leviers réduisent durablement votre exposition à ce risque de dépendance.

1. Des clauses contractuelles claires. Insérez dans vos devis et contrats une mention précisant que l'application repose sur des plateformes tierces dont vous ne maîtrisez ni les tarifs, ni la disponibilité, ni la feuille de route, et que les coûts d'abonnement sont à la charge du client et susceptibles d'évoluer. Cette clause ne vous exonère pas de tout, mais elle déplace clairement la frontière des responsabilités.

2. Une stratégie de portabilité. Prévoyez et documentez l'export régulier des données du client dans un format réutilisable. Une application qui s'arrête est un incident ; une application qui s'arrête et emporte les données du client est une catastrophe dont on vous tiendra rigueur. La capacité à récupérer les données est souvent ce qui distingue un sinistre gérable d'un préjudice majeur.

3. Une assurance calée sur la prestation intellectuelle. Votre métier n'est pas d'écrire des milliers de lignes de code : c'est de concevoir, conseiller et assembler. C'est précisément sur ce terrain du conseil que se jouent les litiges. La RC Professionnelle couvre les dommages immatériels résultant d'une faute de conseil ou d'une erreur de prestation, et finance votre défense si un client conteste votre choix de plateforme.

Le no-code déplace le risque : moins de bugs de code, mais une dépendance massive à des outils que vous ne contrôlez pas. Votre valeur, et votre exposition, se concentrent sur le conseil. Assurez ce que vous êtes vraiment : un architecte de solutions, pas un simple exécutant.

Pour un développeur no-code, l'RC Pro démarre à 9,90 €/mois, avec une option Cyber pertinente dès que vous manipulez des données clients. Le détail des garanties figure sur la fiche développeur no-code.