Nous sommes une agence d'automatisation, nous avons donc un intérêt évident dans ce sujet. C'est aussi pour cela que ce guide vaut la peine d'être écrit : dans les faits, la même appellation recouvre des métiers très différents, du paramétrage d'une plateforme au développement sur mesure, en passant par ceux qui partent du processus. Ce qui suit est notre façon de voir, pas une norme du secteur.
Ces différences comptent davantage que le prix. Se tromper de type de prestataire, c'est finir avec une automatisation élégante posée sur un processus qu'il aurait fallu changer.
Trois métiers, une seule appellation
Aucun des trois n'a tort. Ce sont des réponses à des questions différentes, et c'est le mauvais appariement qui coûte cher.
- L'intégrateur d'outil. Il connaît une plateforme à fond et la configurera bien. Quand le processus entre dans la plateforme, c'est souvent le chemin le plus court vers quelque chose qui tourne. Sinon, le travail bascule dans la logique sur mesure et les contournements, ce qui annule une bonne partie de l'avantage.
- Le studio de développement généraliste. Il construira ce que dit le cahier des charges. Solide quand vous savez exactement ce que vous voulez, risqué quand c'est justement le cahier des charges qu'il faudrait remettre en question.
- Le prestataire qui part du processus. Il passe le début de la mission à comprendre comment le travail se déroule avant de proposer quoi que ce soit, et une partie de ce qu'il proposera ne sera pas du logiciel. Cette phase de découverte coûte du temps en amont, et elle est inutile si vous n'avez besoin que d'une intégration connue entre deux outils standards.
Cinq questions qui les départagent
- Demandez une situation où ils ont conclu que ça ne valait pas la peine d'être automatisé. Leur réponse vous dit comment ils décident de ce qui mérite d'être construit.
- Qui possède les comptes, le code et les automatisations le jour où nous arrêtons de travailler ensemble ? Obtenez la réponse avant de signer, pas à la fin.
- Qu'est-ce qui casse quand l'autre système change ? Quelqu'un qui a exploité des intégrations en production devrait pouvoir dire ce qu'il surveille, quels changements en amont ont déjà cassé des choses, et ce qui se passe quand une synchronisation échoue.
- Racontez-moi une mission qui s'est mal passée. La version utile de cette réponse inclut ce qu'ils ont changé ensuite.
- Travaillerez-vous dans les outils que nous utilisons déjà, ou nous ferez-vous basculer sur les vôtres ? Les deux peuvent se défendre. Vous voulez savoir de quelle conversation il s'agit.
Ce que récompense chaque modèle de prix
Le forfait fonctionne bien quand les besoins sont réellement connus à l'avance. Quand des besoins importants restent à découvrir, chaque nouvelle trouvaille risque de se transformer en discussion de périmètre.
Le tarif journalier fonctionne mieux quand le périmètre comporte une vraie incertitude, mais il exige que vous restiez impliqué, puisque rien d'externe ne borne le total. L'abonnement se justifie surtout une fois qu'un système tourne et demande du suivi ; avant cela, il lui faut un objectif et un livrable très clairs.
Méfiez-vous des prix indexés sur les heures économisées. Cela paraît aligné, mais cela peut récompenser l'automatisation des heures les plus faciles à mesurer plutôt que du travail qui crée le plus de valeur, et vous passerez une partie de la mission à discuter du point de départ.
Quand il ne faut engager personne
- Vous avez besoin d'une seule connexion entre deux outils courants. Regardez d'abord les intégrations natives et les connecteurs no-code habituels : si l'un couvre déjà le flux de façon fiable, il n'y a pas de projet à payer.
- Un produit du marché fait déjà cela et votre objection est l'abonnement. Comparez l'abonnement au coût de construction plus sa maintenance avant de conclure que construire coûte moins cher.
- Quelqu'un en interne est déjà près d'y arriver et a surtout besoin d'une direction technique. Achetez cet accompagnement ciblé plutôt que d'externaliser tout le problème.
- Le processus est sur le point de changer. Il y a en général tout intérêt à attendre, plutôt qu'à graver des décisions que vous savez déjà provisoires.
Où nous nous situons
Notre façon de travailler est la plus proche du troisième modèle. Les missions démarrent sur le processus plutôt que sur une plateforme, et le premier livrable est en général une cartographie chiffrée plutôt qu'un logiciel qui tourne.
Pour Mutualys, un groupe d'assurance santé, cela a abouti à un CRM interne et un chatbot WhatsApp. Leur gestion des demandes était éparpillée entre e-mails, notes téléphoniques et tableurs, et les outils du marché que nous avons examinés ne correspondaient pas à leur façon de qualifier et de relancer un prospect. Une mission qui se termine par un changement de réglage plutôt que par un développement est pour nous un résultat tout aussi acceptable.