Responsable du déploiement de l'IA — tâches, une par une

Décider quoi essayer d'abord

L'entrée qui lie n'est pas la connaissance des outils, c'est la connaissance de cette entreprise : quelle étape est réellement le goulot, de qui les chiffres bougent si elle change, et qui sera fâché. Cette information n'est pour l'essentiel écrite nulle part : elle ne peut donc pas être retrouvée — elle doit être collectée par quelqu'un qui peut circuler et demander.

Difficile à automatiser n'est pas la même chose que durable. Tout ce poste existe parce qu'une transition est en cours ; quand les outils deviendront ordinaires comme les tableurs le sont devenus, choisir quoi automatiser redeviendra une part de la conduite d'une fonction plutôt qu'une fonction à part. La sécurité ici est celle d'un échafaudage.

Le vérifier sur le travail réel de l'entreprise

L'outillage d'évaluation est devenu réellement bon et une bonne part de la notation peut tourner automatiquement. Ce qui ne s'automatise pas est de décider ce qui compte comme correct pour cette entreprise, soit un jugement d'affaires en costume technique — deux maisons qui font la même tâche peuvent avoir des seuils différents pour la même erreur.

Une bonne évaluation vous dit que l'outil fonctionne sur les cas que vous avez pensé à réunir. Elle ne dit rien des cas auxquels personne n'a pensé, et c'est là que vivent les défaillances coûteuses — un score satisfaisant est donc une raison de commencer à surveiller, non une raison d'arrêter.

Le brancher sur ce qui existe déjà

Écrire le code d'intégration est l'une des choses que ces outils font le mieux : la construction est donc devenue bien moins chère. Savoir lequel des quatre systèmes détient la version qui fait foi d'un enregistrement, et quel champ ment discrètement, non — ce savoir vit dans des gens présents depuis des années.

Une intégration bon marché est la raison pour laquelle les pilotes se multiplient et pour laquelle la plupart tournent encore comme pilotes. Pouvoir brancher un outil en une après-midi n'établit pas que quelqu'un a changé sa façon de travailler, et les deux sont rapportés comme la même étape.

Décider ce qu'il peut faire sans surveillance

C'est une répartition de responsabilité, non une tâche de configuration. Décider qu'un outil peut engager l'entreprise sur un prix, une date ou des excuses est une décision sur qui en répond — et un système ne peut pas autoriser sa propre autorité.

Que les garde-fous soient un travail humain ne veut pas dire qu'ils sont écrits. Dans la plupart des entreprises, personne n'a reçu cette tâche : la frontière se règle donc par défaut — par qui a configuré l'outil — et ce défaut est invisible jusqu'à ce que sorte quelque chose qui n'aurait pas dû sortir.

Faire que les gens s'en servent vraiment

L'adoption échoue pour des raisons que les gens ne mettront pas dans un questionnaire : cela fait paraître quelqu'un plus lent, cela retire la part du métier qu'il aimait, c'est un clic plus loin que là où il est déjà. Le découvrir exige de la confiance, et y remédier exige l'autorité de changer le processus.

C'est la tâche la plus susceptible d'être coupée, parce qu'elle est lente et ne produit aucun livrable. Une entreprise qui achète les outils et saute cette étape obtient le coût des licences et le pilote, et rapporte les deux comme un progrès.

Être là quand il se trompe

Chaque retour en arrière public que ce site enregistre a cette forme : la défaillance technique était réparable et le vide de responsabilité ne l'était pas. Quelqu'un doit assumer le résultat devant un client ou un régulateur, et l'assomption est la seule chose qui ne peut pas être déléguée au système qui l'a causée.

Porter le blâme n'est pas détenir l'autorité. Ce poste répond souvent de décisions qu'il ne peut pas contredire — le budget, le fournisseur, l'échéance ont tous été fixés ailleurs — et cette combinaison est la raison la plus fréquente pour laquelle les gens le quittent.