Automatiser avec un outil ou faire développer sur mesure

La question arrive posée comme un duel : Make ou développement ? n8n ou programmer ? Posée ainsi, elle n’a pas de réponse, parce que les deux options sont bonnes et que le choix ne dépend pas de savoir laquelle est la meilleure.

Il dépend d’autre chose, moins évidente : ce qu’il vous en coûterait de tout refaire si, dans deux ans, vous aviez besoin d’autre chose. Parce que vous en aurez besoin.

Ce qu’est chaque chose

Une plateforme d’automatisation — Make, Zapier, n8n, Power Automate — est un canevas où l’on relie des services qui existent déjà : quand un formulaire arrive, crée une ligne, envoie un courriel, préviens par WhatsApp. On l’assemble en faisant glisser des blocs et en configurant chacun d’eux. La plateforme apporte les connexions toutes faites, exécute le processus, le relance s’il échoue et laisse noté ce qui s’est passé.

Le développement sur mesure, c’est écrire le programme qui fait exactement ce qu’il faut, tournant là où vous en décidez. Il n’y a pas de blocs : il y a du code, et avec lui un contrôle total et une responsabilité totale.

La différence de fond n’est pas « facile contre difficile ». C’est l’endroit où restent conservées les règles de votre activité : les étapes, les exceptions, qui décide quoi. Avec une plateforme, elles restent dans le compte d’un prestataire, et on ne peut les lire et les modifier que depuis là. Avec un développement à vous, elles restent dans des fichiers qui sont les vôtres et que vous pouvez emporter ailleurs. Tout le reste découle de cette différence.

Six critères pour décider

1 · À quel point est standard ce que vous voulez relier

Si ce sont des services connus — Google Calendar, un système de gestion de clients répandu, un tableur, le courriel —, la plateforme apporte déjà la connexion vers eux, toute faite et éprouvée par des milliers d’utilisateurs avant vous. Là, elle gagne largement : ce qui prendrait des jours à un programmeur s’assemble en quelques heures.

Si ce qu’il faut relier est un vieux programme maison, ou un service pour lequel la plateforme n’apporte pas de connexion toute faite, il faut la fabriquer à la main à l’intérieur de la plateforme. Là, l’avantage s’arrête : on finit par programmer quand même, mais dans un outil qui n’est pas pensé pour cela. C’est le pire des deux mondes.

2 · Volume

Les plateformes facturent chaque exécution du processus, voire chaque étape à l’intérieur. Avec peu de mouvement, cela revient bon marché. Avec beaucoup, l’abonnement pour le même processus peut finir par coûter plusieurs fois ce que coûte un petit serveur, parce que la facture croît avec l’usage et que le serveur, non.

Faites le calcul avec le volume de l’année prochaine, pas avec celui d’aujourd’hui. C’est la projection qui décide, et c’est elle que presque personne ne fait.

3 · À quel point la logique est embrouillée

Un flux linéaire avec deux ou trois conditions se lit parfaitement sur un canevas visuel. Un flux avec quinze branches, des boucles et des cas particuliers devient un plat de spaghettis que seul comprend celui qui l’a dessiné — et que personne n’ose toucher quand cette personne s’en va.

Le signal d’alarme est concret : quand des cases contenant du code écrit à la main commencent à apparaître dans le canevas — pour résoudre ce que les blocs normaux n’atteignent pas —, vous êtes déjà en train de programmer. Sauf que c’est au pire endroit pour le faire : sans historique de qui a changé quoi, sans pouvoir essayer avant de publier et sans qu’une autre personne puisse relire la modification.

4 · Qui va l’entretenir

Ce critère décide plus souvent que les cinq autres réunis.

S’il y a dans l’entreprise quelqu’un qui a du jugement sans avoir un profil de programmeur, une plateforme lui donne une autonomie réelle : il peut ajuster un texte, ajouter une étape, voir pourquoi quelque chose a échoué. Avec un développement sur mesure, chaque changement passe par un tiers.

S’il n’y a personne — si la maintenance va de toute façon être externe —, cet argument disparaît, et avec lui une bonne part de l’avantage de la plateforme.

5 · Ce qu’il advient des données

Dans une plateforme, les données du processus passent par l’infrastructure du prestataire. Pour la plupart des processus, c’est parfaitement acceptable. Pour des données personnelles sensibles ou des informations soumises à des accords de confidentialité, il faut regarder où elles sont traitées, combien de temps elles sont conservées et ce que dit le contrat. Le critère est dans quelles données ne devraient pas sortir de l’entreprise.

Il vaut la peine de noter que certaines de ces plateformes peuvent s’installer sur une infrastructure à soi — n8n en fait partie —, ce qui les laisse à mi-chemin : le confort d’une plateforme avec les données à la maison. C’est une possibilité que l’on oublie dans cette discussion et qu’il convient d’examiner avant d’écarter la voie de l’outil.

6 · Combien coûte de partir

C’est la question que presque personne ne pose au début, et celle qui coûte le plus cher quand vient le moment d’y répondre.

Un processus construit dans une plateforme ne se déménage pas vers une autre : il se reconstruit, parce que chacune définit les flux à sa manière. Si le prestataire augmente son prix, change ses conditions ou ferme, il faut refaire le travail. Un développement à soi change de serveur avec un effort prévisible. L’exception est l’outil que l’on peut installer sur une infrastructure à soi : là, le changement est de serveur, pas de plateforme.

Cela ne décide pas à soi seul. C’est simplement un coût de plus qu’il convient d’avoir noté dès le début, à côté des autres, et qui ne l’est presque jamais.

Le tableau court

Les trois signaux du point de rupture

Presque personne ne choisit mal au début. Ce qui arrive, c’est qu’on choisit bien et qu’on ne revoit pas. Ces trois signaux disent que la plateforme est devenue trop petite pour vous :

1. La facture mensuelle paie déjà un serveur, et il reste de la marge. Arithmétique simple, et qui passe d’ordinaire sans que personne ne la regarde.
2. Il y a des blocs de code dans le canevas. Vous programmez déjà, au pire endroit possible pour le faire.
3. Personne n’ose toucher au flux. Quand un petit changement fait peur, le système a cessé d’être maintenable, et c’est un problème même si tout fonctionne aujourd’hui.

La réponse qui l’emporte souvent : les deux

En pratique, le plus sain n’est pas d’en choisir une, mais de répartir selon ce qui se passe si quelque chose échoue. Ce qui est en périphérie et change souvent — avis internes, rapports, faire passer des données d’un outil de bureau à un autre — vit très bien sur une plateforme : si cela tombe un après-midi, personne n’est ruiné. Ce qui soutient l’activité et ne peut pas échouer se construit sur mesure.

Ainsi on paie le contrôle là où le contrôle importe et le confort là où le confort suffit. Et pour décider dans lequel des deux groupes tombe chaque processus, les douze questions du guide d’achat sont utiles.

Comment nous pouvons vous aider

Cet article vous donne les six critères et le tableau. Ce qui est difficile, c’est de les appliquer à un cas concret, parce que presque aucun processus ne tombe proprement dans une seule colonne :

• Décider pour votre cas, avec vos six réponses et non celles de l’exemple : ce qui se relie, quel mouvement cela représente, combien d’exceptions, qui va l’entretenir, quelles données sont touchées et ce que coûterait d’en partir. Il en sort une recommandation avec le motif écrit, pas un verdict.
• Le construire sur la plateforme si c’est la réponse, et le laisser documenté pour que quelqu’un de votre équipe puisse y toucher sans crainte. L’autonomie est la moitié de l’avantage d’une plateforme, et elle se perd si personne n’explique comment c’est monté.
• Le développer sur mesure si le cas l’exige, avec les identifiants et les comptes d’infrastructure au nom de votre entreprise, et la propriété du livrable convenue par écrit avant de commencer.
• Le sortir de la plateforme quand les trois signaux apparaissent, sans éteindre ce qui fonctionne déjà pendant que le changement se fait.

Si vous avez un processus en tête et que vous ne savez pas dans laquelle des deux colonnes il tombe, la division technique l’examine avec vous en une réunion de trente minutes et vous dit ce qu’elle recommanderait et pourquoi. Sans frais et sans engagement.

Questions fréquentes

Qu’est-ce qui convient le mieux, Make ou développer sur mesure ?

Cela dépend de six choses : à quel point est standard ce qui se relie, le volume, l’embrouillement de la logique, qui va l’entretenir, ce qu’il advient des données et ce que coûterait d’en partir. En règle générale, il convient de commencer sur une plateforme pour valider que le processus sert, et de reconstruire sur mesure quand la facture paie déjà un serveur, quand il faut écrire du code dans le canevas ou quand personne n’ose toucher au flux.

Est-ce moins cher d’automatiser avec un outil que de programmer ?

Au début, presque toujours oui, parce que le coût de démarrage est bien moindre. À volume élevé et soutenu, cela s’inverse : l’abonnement croît avec l’usage et le développement à soi, non. La comparaison doit se faire avec le volume projeté à un an, pas avec l’actuel.

Peut-on combiner les deux approches ?

C’est le plus courant et d’ordinaire le plus sain. Ce qui est en périphérie et change souvent vit sur une plateforme ; ce qui soutient l’activité se construit sur mesure. Ainsi on paie le contrôle là où il importe et le confort là où il suffit.

Que se passe-t-il si la plateforme d’automatisation augmente son prix ou ferme ?

Un processus construit dans une plateforme ne se migre pas : il se reconstruit dans une autre. Ce coût devrait être envisagé dès le début. Une solution intermédiaire consiste à utiliser un outil pouvant s’installer sur une infrastructure à soi — n8n en fait partie —, qui conserve le confort visuel sans dépendre de la continuité d’un service qui ne vous appartient pas.