Une fenêtre de chat où vous téléchargez un document et recevez un résumé en retour a l'air simple. Ce qui se passe en dessous l'est moins. Le document doit être lu, découpé, interprété à la lumière de ce qui est pertinent pour votre organisation, puis restitué dans une forme utilisable par celui qui le lit. Chaque étape de cette chaîne impose une exigence à l'organisation qui l'entoure. Cette page décrit ce qui doit être en place pour cela, pas quelle part du travail disparaît de ce fait.
La lecture de documents par l'IA englobe une série de tâches souvent regroupées sous un même terme. Résumer un contrat est autre chose que parcourir mille contrats à la recherche d'une clause déviante. Réduire un compte-rendu de réunion à des points d'action est autre chose que ramener un rapport annuel aux risques qui s'y cachent. Ce que ces tâches ont en commun, c'est que la qualité du résultat dépend de la qualité de ce qui est fourni. Un document mal scanné, un format incohérent, ou un texte sans structure claire rend la lecture elle-même incertaine, avant même qu'il soit question de résumer.
La première question n'est pas quel modèle de langage résume le mieux, mais si les documents que vous voulez faire lire sont accessibles et cohérents. Sont-ils dispersés dans des dossiers, des systèmes et des boîtes mail, ou sont-ils organisés à un endroit repérable. Est-il clair quelle version d'un document est la version valide. Les documents contiennent-ils des informations confidentielles qui ne peuvent pas simplement être traitées par un système externe. Ce ne sont pas des détails techniques qui viendront plus tard ; ce sont les conditions qui déterminent si résumer produit quelque chose sur lequel on peut s'appuyer, ou quelque chose qui doit être vérifié à chaque fois.
Vient ensuite la question de savoir comment les documents entrent et sortent du système. Une simple fenêtre de téléchargement fonctionne pour un usage occasionnel, mais qui veut déployer cela de manière structurelle a besoin d'une connexion entre l'endroit où les documents naissent et l'endroit où ils sont lus. Cela demande des liaisons qui ne se rompent pas lors d'une mise à jour, et un moyen de voir quand quelque chose se passe mal. Sans cette connexion, lire et résumer reste une étape manuelle : quelqu'un qui présente sans cesse à nouveau un fichier.
Un résumé n'est utile que si quelqu'un sait qu'en faire. Cela demande des accords : qui contrôle un résumé avant qu'il ne suive son cours, qui est responsable si un détail est manqué, et quelle est la norme définissant un bon résumé. Sans ces accords s'installe soit une habitude où les gens utilisent le résultat sans le vérifier, soit l'inverse, où tout est relu intégralement, ce qui fait disparaître le gain de temps. L'organisation doit en d'autres termes avoir aménagé une place pour ce résultat, pas seulement un système qui le produit.
Dès que des documents sont lus, la question de ce qui en advient surgit rapidement. Un résumé d'une conversation est apparenté à ce que demande la consignation et le suivi des conversations d'une organisation ; un résumé qui doit automatiquement déclencher une action de suivi touche à ce qui est nécessaire pour les agents qui exécutent du travail. Et dès qu'un résumé est utilisé pour étayer un choix, la question se déplace vers ce que l'aide à la décision demande à cette même gestion des données et à ces mêmes accords. Lire des documents est rarement le point final ; c'est généralement le premier maillon d'une chaîne qui va plus loin que ce que montre la fenêtre de chat.
La tentation est de commencer par le modèle qui résume le mieux. Mais un modèle qui résume bien apporte peu si les documents qu'il doit lire sont incohérents, s'il n'y a pas de connexion avec l'endroit où ils naissent, et si personne n'a établi qui contrôle le résultat. Organisation, infrastructure et gestion des données passent en premier : ce n'est pas un ordre de préférence, mais l'ordre dans lequel cela fonctionne. Une organisation qui n'a pas ces fondations en ordre voit un pilote qui a l'air bien dans une démonstration, mais qui s'enlise dès que les documents sont moins propres que le fichier de test.
Cette page décrit ce qui doit être en place avant que la lecture et la synthèse de documents ne produisent quelque chose sur quoi une organisation peut construire. Elle ne répond pas à la question de savoir quelle part du travail actuellement lié aux documents peut réellement être reprise. C'est une autre question, qui varie selon la tâche et le document, selon le degré de répétabilité du travail et la quantité de contexte nécessaire pour le faire correctement.
Le scan de travail de FTE TO AI calcule cela : pour chaque tâche, il détermine quelle part du travail peut être reprise par l'IA, compte tenu de la nature du travail et des conditions qui s'y appliquent. Là où cette page décrit la préparation de l'organisation, le scan de travail cartographie ce qui, une fois cette préparation en place, se déplace réellement.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.