À quelle échéance juger un système
Une année passée d’un client à l’autre. On y voit de près comment une ligne budgétaire « IA » est retenue ou rejetée en comité, et à quel horizon on devrait juger un système.
Une année entière passée d’un client à l’autre, entre une usine numérique de groupe et un accélérateur pharmaceutique. Changer de client tous les six mois enseigne une chose : la vraie question d’un système est ce qu’il devient une fois qu’on est parti. L’année qui vient devrait m’amener vers des missions plus longues, et je m’aperçois que c’est ce que je cherche.
Il traite l’IA comme un investissement à justifier, avec des critères d’abandon écrits d’avance. Le chapitre le plus utile explique comment arrêter un projet sans le déguiser en succès.
Il propose de juger un système à ce qu’il devient quand on cesse de s’en occuper. C’est exactement le critère d’une passation, et je n’en ai pas trouvé de meilleur depuis.
Un siècle de recul sur la complexité, écrit court. Ce qu’il en reste pour un praticien : la tentation de simplifier un système est presque toujours la tentation d’en ignorer une partie.