Comment se déroule le déploiement d’un système d’IA
Un système capable et un système utilisé sont deux objets différents, et le chemin entre les deux compte cinq étapes dont une seule est de la construction. Les quatre autres sont l’établissement du problème réel, l’obtention d’un accès aux données, l’intégration dans des systèmes qui existaient avant vous, et l’adoption par des personnes qui n’ont rien demandé. Les projets qui échouent ne butent presque jamais sur l’étape de construction : la technique actuelle traite correctement la majorité des problèmes qu’on lui soumet. Ils meurent en amont, en attendant une autorisation d’accès qui n’arrive pas, ou en aval, quand le système fonctionne et que personne ne s’en sert. Ces deux étapes sont les plus ennuyeuses à planifier et les seules qui décident du résultat. Un calendrier qui leur accorde autant de place qu’au développement est un calendrier qui a des chances d’être tenu, et c’est malheureusement rarement celui qui est présenté en comité d’investissement.
Étape un : établir le problème réel
Le problème énoncé est presque toujours une traduction du problème réel, et la traduction perd quelque chose. On vous demande d’automatiser la rédaction d’un compte rendu ; en regardant, on découvre que la rédaction prend vingt minutes et que la recherche des informations à y mettre en prend deux heures.
La seule méthode fiable consiste à regarder le travail se faire, plusieurs fois, et à chronométrer sans chercher à être discret. Les entretiens produisent la version idéalisée du processus, celle qui figure dans les procédures. L’observation produit la version réelle, y compris les contournements que personne ne mentionne parce qu’ils sont devenus invisibles à force d’être quotidiens.
Étape deux : obtenir l’accès aux données
C’est la première des deux étapes qui tuent. Une demande d’accès en lecture à une base de production s’écrit en une ligne et s’obtient en cinq semaines dans un groupe bancaire, en deux jours dans une société de quarante personnes. L’écart entre ces deux mondes est la variable qui explique le mieux la durée d’un projet, bien avant sa difficulté technique.
Deux conséquences pratiques. D’abord, cette demande se lance le premier jour, avant même d’avoir décidé quoi construire, parce que le délai court de toute façon. Ensuite, la personne capable de l’accorder doit être identifiée nommément pendant le diagnostic : un projet dont le porteur ne sait pas qui autorise l’accès découvrira en semaine quatre qu’il s’agit d’un comité mensuel.
La deuxième mauvaise surprise arrive une fois l’accès obtenu. Les données ne ressemblent presque jamais à leur documentation : un champ supposé renseigné l’est à soixante pour cent, et les quarante pour cent manquants suivent une logique que seule une équipe opérationnelle connaît. Cette découverte est normale et doit être budgétée, pas subie.
Étape trois : construire
C’est l’étape la plus courte et celle dont tout le monde parle. Elle se passe bien quand deux règles sont respectées.
La première est de mettre quelque chose devant un utilisateur réel dans les premières semaines, aussi incomplet soit-il. La première version sera fausse sur un point que personne n’avait anticipé, et ce point n’apparaît qu’au contact. Le découvrir en semaine trois coûte deux jours ; le découvrir en semaine douze coûte le projet.
La seconde est de construire le jeu d’évaluation avant le système, avec les experts du client. Ce n’est pas un instrument de mesure, c’est un instrument d’accord : la discussion sur ce qui constitue une bonne réponse fait remonter les désaccords internes qui, sinon, seraient apparus trois mois plus tard sous la forme d’une affirmation selon laquelle le système ne marche pas.
Étape quatre : intégrer
L’intégration est la partie la moins intéressante et la plus sous-estimée. Authentification, autorisations, formats d’échange, systèmes amont indisponibles pendant la maintenance mensuelle, fenêtres de mise en production imposées. Rien de tout cela n’est difficile, et tout cela prend un temps que les devis ne prévoient pas.
La règle utile est de traiter le pire cas d’intégration dès le début plutôt qu’à la fin. Si un système amont est connu pour son instabilité, c’est par lui qu’il faut commencer : un projet qui découvre en dernière semaine qu’une intégration critique est impossible a déjà dépensé tout son budget.
Étape cinq : l’adoption
La seconde étape qui tue, et la plus douloureuse parce que tout fonctionne. Le système est juste, rapide, intégré, et trois mois plus tard les gens ont repris leur ancienne méthode.
Les causes se réduisent souvent à trois. La personne concernée est évaluée sur l’ancienne façon de faire, et aucune note de service ne change une mesure de performance. Elle ne fait pas confiance au résultat, parce qu’elle a vu le système se tromper une fois avec assurance sur un cas qu’elle connaissait. Ou bien personne ne lui a jamais dit ce qu’elle devait faire du temps ainsi libéré, et le temps s’est reconstitué ailleurs.
Aucune de ces causes n’est technique, et aucune ne se règle par une formation. Elles se règlent en s’asseyant à côté des gens pendant les semaines qui suivent la mise en service, ce qui est du travail réel et doit figurer au planning au même titre que le développement. Un projet qui prévoit zéro jour d’adoption a décidé, sans le dire, que l’usage ne fait pas partie du périmètre.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
