Le “vendor locking” est un problème commun dans de nombreux domaines technologiques, y compris dans le monde du no-code. On peut le définir comme la dépendance d'un utilisateur à un fournisseur de services, qui peut limiter sa capacité à changer de fournisseur ou à s'adapter à de nouveaux environnements. Dans le contexte des outils no-code, cela signifie que vous pouvez être enfermé par une application donnée voire par le prestataire qui vous a accompagné sur l’intégration de l’outil.
Les outils no-code sont souvent caractérisés par des fonctionnalités propriétaires qui sont conçues pour être utilisées sur leur propre plateforme. C’est dans l’intérêt de l’outil de vous garder le plus longtemps. C’est d’ailleurs un des indicateurs le plus regardé dans le monde des SaaS : le taux d’attrition (le pourcentage de clients perdus qui ne renouvellent pas leurs achats ou qui quittent l’entreprise sur une période donnée). Mais l’intérêt de l’éditeur n’est pas aligné avec le vôtre. Votre intérêt est d’être libre. L’éditeur va donc tout faire pour vous faire rester :
Mais l’enfermement peut aussi venir des prestataires de services :
Ces pratiques vont restreindre votre liberté de changer d’outils et de prestataires. Quelles en sont les conséquences ?
Qui dit manque de liberté, dit dépendance. Vous devenez dépendant d’un produit ou d’un service et vous n’avez plus de levier de négociation auprès de lui.
Prenons Zapier, outil d’automatisation facile d’utilisation, gratuit dans un premier temps et que l’on recommande chaudement d’ailleurs pour commencer dans le merveilleux monde des automatisations.
Ils s’intègrent avec tous les outils, du coup vous allez connecter un, puis deux, puis cinq outils entre eux. Vous allez construire une série de “zaps” (scénario d’automatisation), comprendre la puissance de l’automatisation. Rapidement vous allez devoir passer sur un plan supérieur, puis un autre. Puis sans vous en rendre compte (ou presque), pour vos 10.000 opérations par mois, vous allez devoir payer plus de 100€ mensuellement.
On va donc vous dire de passer sur Make qui pour le même nombre d’opérations coûtent 10 fois moins cher. Sauf que vous allez devoir migrer toutes vos automatisations d’un service à un autre. Tout refaire. Tout reconnecter. Tout tester. Avec une logique un peu différente parfois. Coût de migration : entre 1000 et 5000€ selon le nombre de vos automatisations. Du coup, vous allez peut-être rester sur Zapier. Pour combien de temps et donc d’argent ?
Si vous ne jurez que par un outil, vous risquez de vous faire enfermer dans sa façon de fonctionner et ses fonctionnalités.
Si l’outil ne permet pas de faire certaines choses, vous allez procéder à des contournements, alors que potentiellement c’était le bon moment pour changer d’outils.
Si vous parlez à un expert Softr qui ne maîtrise que cet outil, il ne saura pas forcément bien vous conseiller sur le moment où il faudra passer sur WeWeb ou Bubble. Si vous parlez à un expert Gilde, il vous conseillera Glide pour tous vos besoins, alors que cela ne sera pas toujours l’outil le plus pertinent en fonction de votre besoin.
C’est d’ailleurs pour cela que chez Bienfait nous voulons rester agnostiques des outils. Certes, nous ne serons pas les meilleurs sur certains outils, mais au moins nous ne serons pas enfermés.
Le no-code redonne le contrôle, mais si vous confiez sa puissance à un éditeur ou à un prestataire, vous risquez de perdre la main.
Oui pour confier une partie de vos outils chez des éditeurs et des prestataires, non à la dépendance totale vis-à-vis d’eux.
Tout d'abord, il est important de sélectionner des outils qui sont compatibles avec d'autres outils et plateformes. De plus en plus (bien que nous alertions sur le contraire un peu plus haut), les outils no-code sont ouverts, que ce soit de par leurs APIs ou par des fonctionnalités d’import et d’export efficaces.
Ensuite, il va être important de choisir l’outil le plus adapté au besoin du moment et au besoin du futur proche afin de limiter les changements d’outils, qui peuvent être coûteux. C’est un doux et savant mélange entre la sélection d’un outil un tout petit peu surdimensionné par rapport au besoin actuel mais pas trop non plus pour être pertinent tout de suite. Cela nécessite une connaissance des forces et faiblesses des outils du marché, de leurs fonctionnalités et de leurs plans tarifaires.
Nous l’évoquons dans beaucoup de nos articles mais il est important de le rabâcher : documentez. La documentation est une des clés pour garder la main sur vos outils, que ce soit vis-à-vis d’un éditeur pour migrer vers un autre outil, ou vers un prestataire pour reprendre l’administration d’un produit.
Pour finir, il nous paraît primordial d’insister sur ce point : développer des compétences transférables vous rendra libre. Libre de travailler sur plusieurs plateformes no-code, de bénéficier du meilleur de chaque outil mais aussi d’utiliser au mieux les compétences des têtes bien faites qui travailleront sur vos projets.
Une des promesses du no-code est la liberté : liberté de créer sans savoir coder, liberté de faire les choses par soi-même, liberté de tester, liberté d’échouer, liberté d’apprendre.
Ne donnez pas votre liberté à n’importe qui et à n’importe quel prix.
Gardez en tête (bien faite) nos recommandations.
On entend beaucoup parler de no code et son impact sur les process en entreprises mais comment savoir si votre projet no code tient ses promesses ?
La panoplie d'outils no-code peut rapidement nous perdre et nous décourager. Chez Bienfait, on en a bien conscience, c'est pourquoi on s'est dit que vous expliquer comme cadrer sa stack pouvait être une bonne idée.
Nous en avons vu des projets des no-code depuis notre lancement, nous en avons repris certains, nous en avons vu de loin et nous avons constaté que les mêmes erreurs se répétaient tout le temps.
