Douze questions avant d’engager une automatisation

Engager une automatisation ou un système avec IA a un problème structurel : celui qui achète ne peut presque jamais évaluer techniquement ce qu’on lui propose. L’issue habituelle est de demander trois devis et de choisir celui du milieu, ce qui est une façon élégante de décider au hasard.

Il y a une alternative. Nul besoin de comprendre la technologie : il suffit de poser douze questions et d’écouter la forme de la réponse. Un prestataire qui a déjà construit cela répond avec des détails concrets ; celui qui ne l’a pas fait répond avec des adjectifs.

Sous chaque question figurent ce qui devrait vous rassurer et ce qui devrait vous inquiéter.

Sur le périmètre

1 · Qu’est-ce qui reste en dehors de ce projet ?

Rassurant : une liste concrète. « Cela n’inclut pas la migration des données historiques, cela n’inclut pas de formation au-delà de deux sessions, cela n’inclut pas de modifications du système comptable. »

Inquiétant : « Tout ce dont vous aurez besoin. » Personne ne peut livrer tout ce dont vous aurez besoin à prix fermé, et qui le dit reporte la discussion au moment où vous aurez déjà versé l’acompte.

2 · De quoi avez-vous besoin de ma part, et pour quand ?

Rassurant : une liste avec des dates et des noms. Des accès, des informations, des décisions, une personne disponible pour les questions.

Inquiétant : qu’on ne vous demande absolument rien. Il est normal qu’un prestataire prenne en charge tout ce qui est technique — c’est pour cela qu’on l’engage —, mais la connaissance de l’activité, vous seul l’avez : quelles exceptions existent, qui décide quoi, ce qui cloche aujourd’hui dans le processus. Si personne ne vous interroge là-dessus, ils vont le supposer, et ils vont le supposer mal.

3 · Que se passe-t-il si, au milieu du projet, nous découvrons que le processus doit changer ?

Rassurant : un mécanisme écrit. Comment se chiffre un changement, qui l’approuve, comment il affecte la date.

Inquiétant : « On verra ça. » On verra, en effet, et ce sera une conversation inconfortable avec le travail à moitié fait.

Sur la façon dont c’est construit

4 · Qu’est-ce que décide le modèle d’IA et qu’est-ce qui est validé dans le code ?

Rassurant : une séparation claire. « Le modèle interprète ce que demande le client ; les horaires, les durées et la capacité, c’est le programme qui les valide avant d’écrire quoi que ce soit. »

Inquiétant : « L’IA se charge de tout. » Un modèle de langage est probabiliste : il a raison presque toujours, et ce « presque », sur un agenda ou un inventaire, c’est une erreur de temps en temps. Le pourquoi est dans qu’est-ce qu’un agent d’IA.

5 · Que se passe-t-il quand un système externe ne répond pas ?

Rassurant : un comportement prévu. Des relances, un avertissement, une réponse honnête au client final.

Inquiétant : le silence, ou « ça n’arrive pas ». Cela arrive. Les services tombent, les quotas s’épuisent et les identifiants expirent.

6 · Comment cela remonte à une personne, et comment lui rend-on le contrôle ?

Rassurant : que l’aller et le retour existent tous les deux. Quand il fait remonter, qui il prévient, comment il se tait pendant que la personne s’en occupe et comment il se réactive.

Inquiétant : que seul l’aller ait été pensé. Un système qui interrompt son propre propriétaire pendant qu’il s’occupe d’un client cause plus de dégâts qu’il n’en évite.

7 · Où sont conservées les données, combien de temps et qui peut les lire ?

Rassurant : des réponses précises, avec un pays et un délai, et la disposition à l’inscrire au contrat.

Inquiétant : « Dans le nuage, tout chiffré. » Cela ne répond à aucune des trois questions. Si vous traitez des données de clients, le cadre est dans la Ley 8968, la loi costaricienne de protection des données personnelles.

Sur l’argent

8 · Combien cela va-t-il coûter le mois prochain, et de quoi cela dépend-il ?

Rassurant : le coût détaillé par parties — consommation du modèle, messagerie, infrastructure, assistance — et quelle variable fait bouger chacune.

Inquiétant : un chiffre mensuel unique et sans explication. Les coûts à l’usage montent avec l’usage, ce qui est justement ce que vous espérez qu’il arrive si le projet réussit.

9 · Que se passe-t-il si le prestataire du modèle augmente son prix ou retire la version ?

Rassurant : qu’ils aient pensé à changer de modèle, et qu’ils sachent ce qu’il faudrait réessayer avant de tenir le changement pour bon : les instructions données au modèle, les cas rares et ce qu’il répond dans ces cas-là.

Inquiétant : que la question les surprenne. Les prestataires de modèles changent leurs prix et retirent des versions régulièrement.

10 · Qu’est-ce que la maintenance inclut et qu’est-ce qui se facture à part ?

Rassurant : la frontière dessinée. Corriger une panne, c’est de la maintenance ; ajouter une fonction, c’est un nouveau projet.

Inquiétant : qu’il n’y ait pas de maintenance dans la proposition. Un système en production a besoin de soin ; s’il n’est pas chiffré, on vous le facturera plus tard ou on ne vous le donnera pas.

Sur le jour d’après

11 · Si demain nous cessons de travailler ensemble, que me reste-t-il ?

C’est la plus importante des douze questions, et la bonne réponse dépend de ce que vous êtes en train d’acheter.

S’il s’agit d’un développement sur mesure, il est raisonnable que le livrable reste à votre nom contre paiement complet, avec les identifiants à votre nom et une documentation suffisante pour qu’un autre puisse continuer. Le prestataire se réserve d’ordinaire ses composants génériques et ses outils propres, et c’est normal : ils sont à lui et il les utilise dans tous ses projets.

S’il s’agit d’une plateforme par abonnement, le code appartient au prestataire et il n’y a pas de sens à le demander — pas plus que vous ne demandez le code de votre système de facturation. Ce que vous devez en revanche exiger, c’est ce qui vous permet de partir : que vos données et votre configuration soient à vous, qu’on vous les remette dans un format d’usage courant et avec un délai écrit, et que le jour où vous déciderez de changer, cela ne dépende de la bonne volonté de personne.

Inquiétant, dans les deux cas, la même chose : que personne ne sache vous répondre, ou que la réponse soit que tout vit dans les comptes du prestataire et y reste. Ce n’est pas un service : c’est une clé que quelqu’un d’autre détient.

12 · Qui a construit cela avant, et qu’est-ce qui a mal tourné ?

Rassurant : une histoire concrète de quelque chose qui a échoué et de la façon dont cela s’est corrigé. Qui a mis des systèmes en production a des cicatrices et les raconte sans drame.

Inquiétant : que rien n’ait jamais mal tourné. Soit ils n’ont rien mis en production, soit ils ne vont pas vous le raconter ; aucune des deux n’est bon signe.

Comment utiliser la liste

Ne la lisez pas d’une traite pendant la réunion : les trois ou quatre qui s’appliquent à votre cas suffisent à distinguer. Et deux signaux de forme valent autant que les réponses :

• Ils vous posent plus de questions qu’ils n’en répondent. Bon signe. Qui va construire quelque chose de sérieux a d’abord besoin de comprendre votre processus.
• Ils vous déconseillent quelque chose. Très bon signe. Un prestataire qui vous dit qu’un processus ne vaut pas la peine d’être automatisé renonce à facturer pour vous dire la vérité.

Si vous voulez confronter un devis que vous avez déjà sur la table, la division technique le fait lors de la réunion initiale. Y compris quand la conclusion est que le devis que vous avez est bon.

Questions fréquentes

Que dois-je demander avant d’engager une automatisation ?

Au minimum quatre choses : ce qui reste en dehors du périmètre, ce que décide le modèle d’IA et ce qui est validé dans le code, combien cela coûtera le mois suivant et de quoi cela dépend, et ce qu’il vous reste si demain la relation avec le prestataire se termine. Cette dernière est celle qui protège le plus : le code, les identifiants, les données et l’infrastructure devraient rester au nom de votre entreprise.

Comment savoir si un prestataire d’IA sait ce qu’il fait ?

Par la forme des réponses plus que par leur contenu. Qui a mis des systèmes en production répond avec des détails concrets, pose plus de questions qu’il n’en répond, peut raconter quelque chose qui a mal tourné, et vous déconseille parfois d’automatiser quelque chose. Qui répond avec des adjectifs et promet que l’IA se charge de tout n’a probablement rien exploité de tout cela.

Est-il normal que le coût mensuel d’une automatisation soit variable ?

Oui, quand il y a de la consommation de modèles d’IA ou de la messagerie en jeu, parce que cela se paie à l’usage. Ce qui n’est pas normal, c’est qu’on ne vous l’explique pas : le devis devrait détailler quelle part est fixe et quelle part croît, et avec quelle variable elle croît.

Dois-je demander que le code reste à mon nom ?

Cela dépend de ce que vous engagez. Dans un développement sur mesure, c’est raisonnable, contre paiement complet, et il convient de le convenir par écrit avant de commencer ; le prestataire retient normalement ses composants génériques, qu’il utilise dans tous ses projets. Dans une plateforme par abonnement, le code appartient au prestataire et le demander ne mène nulle part : ce qui s’y convient par écrit, c’est que les données et la configuration sont à vous, dans quel format on vous les remet et en combien de jours. Dans les deux cas, ce qu’il faut, c’est qu’un autre puisse continuer le travail si un jour c’est nécessaire.