Comment rédiger un RFP pour un logiciel d'extraction de documents qui obtient de vraies réponses

La plupart des RFP pour un logiciel d'extraction de documents sont rédigés à l'envers. Ils commencent par lister les fonctionnalités que l'acheteur pense nécessiter — « doit prendre en charge PDF, JPG et PNG », « doit exporter vers Excel et CSV » — puis distribuent cette liste aux fournisseurs qui cochent toutes les cases sans hésiter car, eh bien, tous les outils de cette catégorie font cela. Le résultat : une pile de propositions identiques, évaluées selon des critères qui n'ont jamais départagé personne. Cet article inverse ce schéma : commencez par vos documents, votre équipe et votre tolérance aux erreurs, puis construisez des questions qui forcent les fournisseurs à révéler leurs véritables différences.

Le véritable objectif d'un RFP (ce n'est pas ce que vous croyez)

L'objectif affiché d'un RFP est la sélection d'un fournisseur. Le véritable objectif — celui qui détermine si vous choisissez le bon outil ou si vous perdez six mois sur une mauvaise implémentation — est tout autre.

Un RFP force votre organisation à répondre aux questions qu'elle évitait jusqu'ici. Quels documents traitez-vous réellement ? Combien ? Que signifie « suffisamment précis » pour votre flux de travail ? Qui exploitera l'outil une fois le contrat signé par les achats ? Si vous ne pouvez pas répondre à ces questions, aucun fournisseur ne pourra y répondre à votre place — et tout outil que vous choisirez est un pari déguisé en décision. Le même principe sous-tend notre cadre d'évaluation des logiciels d'extraction de données : chaque critère qui compte est une question sur votre activité, pas une fonctionnalité à cocher sur la liste d'un fournisseur.

Le livrable le plus précieux d'un RFP n'est pas le contrat signé. C'est le document d'alignement interne créé pendant la rédaction. Les questions auxquelles vous ne pouvez pas répondre sans débat interne sont celles qui auraient fait couler l'implémentation plus tard.

C'est pourquoi la plupart des modèles de RFP fournis par les fournisseurs — ceux que vous pouvez télécharger sur le blog de Rossum, Klippa ou de toute autre société d'IDP — ne vous mènent qu'à mi-chemin. Ils structurent le document, mais ils sont conçus pour être faciles à traiter pour les fournisseurs. Le modèle demande « prenez-vous en charge les PDF multipages ? » et tous les fournisseurs répondent oui. Ce que vous auriez dû demander, c'est : « nous recevons des polices d'assurance de 40 pages avec annexes, tableaux scindés et notes manuscrites en marge — voici trois échantillons — décrivez comment votre système gère le tableau de continuation de la page 27 lorsqu'il n'a pas de ligne d'en-tête. »

La différence entre « prenez-vous en charge le PDF ? » et « voici nos documents — montrez-nous l'extraction » est la différence entre un exercice d'achat et une décision d'achat.

Avant de rédiger la moindre question : définissez la réalité de vos documents

Tout RFP d'extraction de documents devrait commencer par une section que la plupart des modèles ignorent complètement : une description franche de l'apparence réelle de vos documents. Pas de ce que vous aimeriez qu'ils soient. Pas du plus bel exemple que vous puissiez trouver. Le document médian de votre file d'entrée.

Rassemblez 8 à 10 échantillons représentatifs issus de vos flux de travail réels. Ne sélectionnez pas les plus propres. Incluez :

Le PDF scanné qui a été imprimé, tamponné, puis scanné à nouveau à 150 DPI
La photo qu'un collaborateur a prise d'un reçu avec son téléphone dans un restaurant mal éclairé
Le document multipage dont les lignes d'articles s'étendent sur plusieurs pages sans répéter l'en-tête
Le document comportant des annotations manuscrites dans les marges et des tampons qui se chevauchent
Le fax de 2019 légèrement incliné avec un fond gris

Annotez chaque échantillon en marquant les champs à extraire — nom du fournisseur, date, lignes d'articles, totaux, identifiants fiscaux, tout ce qui compte pour votre activité. Cet ensemble annoté devient l'annexe la plus importante de votre RFP. Il permet aux fournisseurs d'éviter l'appel de découverte « à quoi ressemblent vos documents ? » et de démontrer directement leurs capacités.

Si vous envoyez cette annexe à cinq fournisseurs et que trois d'entre eux répondent « nous devrons les voir lors d'un appel », vous avez déjà appris quelque chose que ces trois-là ne voulaient pas vous faire savoir avant la signature du contrat.

La structure de RFP en 7 sections (et ce que chaque section teste réellement)

Chaque section de RFP doit remplir deux fonctions : recueillir des informations et tester une hypothèse sur le fournisseur. Si une section ne fait que recueillir des informations, c'est un formulaire. Si elle ne teste rien, c'est de l'espace perdu. Voici les sept sections qui font les deux — et ce que vous sondez réellement avec chacune d'elles.

Section 1 : Réalité des documents

Ce que vous testez réellement : Le fournisseur peut-il traiter vos documents, et pas seulement les échantillons propres de sa page de démonstration ?

La plupart des RFP commencent par « Présentation de l'entreprise ». Passez cela. Commencez par vos documents. Joignez l'ensemble d'échantillons annotés. Exigez que les fournisseurs renvoient une extraction complète pour chaque document échantillon, en indiquant précisément les champs capturés, ceux manqués et la manière dont ils traiteraient les cas limites que vous avez annotés.

Questions qui distinguent les vrais outils des simples cases à cocher :

« Ci-joint 10 échantillons de documents issus de nos flux de travail réels. Pour chaque échantillon, fournissez le résultat d'extraction pour ces champs : [votre liste de champs]. Signalez tout champ que vous ne pouvez pas extraire avec certitude et expliquez pourquoi. »
« L'échantillon n° 4 contient un tableau de lignes d'articles qui s'étend sur les pages 2 et 3 sans répéter la ligne d'en-tête en page 3. Décrivez l'approche de votre système face à ce scénario — déduit-il la continuation à partir de la mise en page, ou exige-t-il la présence de la ligne d'en-tête ? »
« L'échantillon n° 7 est une photo prise avec un téléphone sous un éclairage de bureau. Votre système effectue-t-il un prétraitement automatique (redressement, ajustement du contraste, réduction du bruit) avant l'extraction ? Si oui, décrivez le pipeline. »

Ne demandez pas : « Prenez-vous en charge les formats JPG, PNG et PDF ? » Tous les outils le font. Cette question ne vous apprend rien.

Demandez plutôt : « Voici à quoi ressemblent nos documents. Montrez-nous l'extraction. » Cela oblige les fournisseurs à démontrer, pas à affirmer.

Section 2 : Exigences d'intégration

Ce que vous testez réellement : Les données extraites arrivent-elles là où votre équipe travaille vraiment — ou créent-elles un nouveau silo ?

Les données extraites ont une destination. Elles vont dans votre ERP, votre système comptable, votre base de données ou le tableur de quelqu'un. La question de l'intégration n'est pas « avez-vous une API ? » — mais « les données arrivent-elles dans le schéma et le système attendus par mon processus en aval, sans étape de reformatage manuel entre les deux ? »

Questions qui font apparaître de vraies frictions d'intégration :

« Nous exportons les données extraites vers [nom du système, ex. QuickBooks Online / SAP / NetSuite]. Décrivez le chemin de bout en bout, de l'extraction à l'arrivée dans notre système — incluez toute étape intermédiaire, conversion de format ou action manuelle requise. »
« Si nos noms de champs ne correspondent pas exactement au schéma du système de destination (ex. notre extraction produit "Vendor Name" mais l'ERP attend "Supplier Name"), votre système prend-il en charge le mappage des champs sans développement personnalisé ? »
« Fournissez-vous des webhooks ou des déclencheurs événementiels pour que notre système en aval traite les données dès la fin de l'extraction, ou l'export est-il une étape manuelle ? »

À ne pas demander : « Avez-vous une API ? » C'est une question fermée à laquelle tous les fournisseurs répondent oui.

À demander : « Décrivez-nous le chemin exact, de l'extraction à notre ERP. Où un humain intervient-il sur les données ? »

Section 3 : Exigences de précision

Ce que vous testez réellement : Que signifie « précis » pour votre activité — et le fournisseur peut-il le définir en termes mesurables ?

Tous les fournisseurs revendiquent une précision de 95-99 %. Ce chiffre correspond presque toujours à la précision OCR au niveau caractère sur du texte propre — pas à la précision d'extraction au niveau champ sur vos documents réels. C'est une métrique marketing, pas opérationnelle.

La vraie question de précision est : parmi les champs qui vous importent, combien reviennent corrects au premier passage, et quel est le flux de correction pour ceux qui ne le sont pas ?

Questions qui forcent des réponses chiffrées :

« Pour les 10 documents d'exemple que nous avons fournis, indiquez la précision d'extraction au niveau champ — chaque champ est soit correct, soit incorrect. Ne rapportez pas la précision OCR au niveau caractère. »
« Quand un champ est extrait avec une faible confiance, que se passe-t-il ? Décrivez l'interface de révision. Un relecteur peut-il voir l'extrait du document original à côté de la valeur extraite ? Peut-il la corriger directement ? »
« Si nous identifions une erreur d'extraction systématique (ex. le système lit systématiquement "O" comme "0" dans les numéros de facture d'un fournisseur spécifique), comment la corriger définitivement ? Votre système apprend-il des corrections, ou devons-nous configurer des règles ? »

À ne pas demander : « Quel est votre taux de précision ? » Vous obtiendrez un chiffre marketing.

À demander : « Voici nos documents. Montrez-nous votre précision au niveau champ. Montrez-nous comment corriger les erreurs. »

Section 4 : Évolutivité

Ce que vous testez réellement : L'architecture de l'outil correspond-elle à votre trajectoire de volume — ou atteint-elle une limite précisément au moment où l'automatisation devient la plus utile ?

L'évolutivité comporte deux dimensions : le volume (combien de documents par mois) et la variété (combien de types et de mises en page de documents différents). Un outil qui fonctionne parfaitement sur 50 factures par semaine peut s'effondrer à 500 — ou gérer 5 000 tout aussi facilement. Le point d'inflexion dépend de l'architecture de l'outil, pas de son marketing.

Questions qui correspondent à votre réalité :

« Nous traitons actuellement environ [N] documents par mois sur [M] types de documents. Nous prévoyons d'atteindre [X] documents par mois d'ici 18 mois. À quel volume votre modèle tarifaire ou votre architecture de traitement change-t-il significativement ? »
« Si nous ajoutons un nouveau type de document six mois plus tard — par exemple, l'extraction de contrats en plus du traitement des factures — à quoi ressemble le processus de configuration ? Devons-nous entraîner un nouveau modèle, configurer de nouveaux modèles, ou simplement définir de nouveaux champs ? »
« Décrivez vos capacités de traitement par lots. Si nous téléversons 200 documents à la fois, pouvons-nous examiner et exporter tous les résultats en une seule session, ou le système les traite-t-il un par un ? »

À ne pas demander : « Votre solution est-elle évolutive ? » Tous les fournisseurs répondent oui.

À demander : « À quel volume le comportement de votre outil change-t-il ? À quel volume votre modèle tarifaire atteint-il ses limites ? »

Section 5 : Exigences opérationnelles

Ce que vous évaluez réellement : Qui, dans votre organisation, utilisera cet outil au quotidien — et l'interface correspond-elle à son niveau de confort technique ?

C'est la section où la plupart des RFP passent discrètement sous silence la question la plus importante. La personne qui évalue les outils (vous, en train de lire ceci) n'est souvent pas celle qui utilisera l'outil chaque jour. Si votre agent de comptabilité fournisseurs a besoin de deux semaines de formation pour extraire une facture, l'implémentation a déjà échoué — peu importe la puissance du moteur.

Les outils de cette catégorie couvrent un large spectre d'utilisabilité. À un extrême, certaines plateformes vous demandent de définir des noms de colonnes en langage naturel et de téléverser des documents — sans formation, sans configuration de modèle. À l'autre extrême, vous étiquetez 50 documents d'exemple par type de document, vous entraînez des modèles par fournisseur et vous configurez des pipelines d'extraction via des panneaux d'administration qui supposent que vous maîtrisez les concepts d'OCR. Les deux approches ont leur place, mais placer la mauvaise devant la mauvaise équipe est le chemin le plus rapide vers un logiciel qui prend la poussière.

ImageToTable.ai se situe à l'extrémité à faible friction de ce spectre grâce à son approche Custom Column Extraction : vous saisissez les noms de champs souhaités — « Vendor Name », « Invoice Date », « Line Total » — et l'IA localise chaque valeur en comprenant ce qu'elle signifie sémantiquement, et non en faisant correspondre une coordonnée de modèle. Aucun étiquetage d'exemple, aucun entraînement de modèle. Les colonnes que vous nommez deviennent les en-têtes de votre tableau de sortie. Pour les équipes sans service informatique dédié, c'est la différence entre être opérationnel en un après-midi et attendre un projet d'implémentation.

Questions qui révèlent la véritable expérience utilisateur :

« Chronométrez un nouvel utilisateur : de la création du compte à l'obtention d'un fichier Excel correctement formaté contenant les données extraites de l'un de nos documents d'exemple. Combien de temps cela prend-il ? Fournissez un enregistrement d'écran du processus. »
« Si un agent de comptabilité fournisseurs sans bagage technique doit traiter le format de facture d'un nouveau fournisseur, quelles étapes suit-il ? Doit-il impliquer l'informatique ou configurer quoi que ce soit ? »
« Décrivez le flux de correction lorsqu'une erreur d'extraction est détectée. L'utilisateur peut-il la corriger directement dans votre interface, ou doit-il exporter vers Excel, corriger là-bas, puis re-téléverser ? »

Ne demandez pas : « Votre outil est-il convivial ? » C'est la question la plus dénuée de sens dans tout RFP logiciel.

Demandez plutôt : « Enregistrez une capture d'écran d'un utilisateur découvrant l'outil en train de traiter l'un de nos documents. Montrez-nous le parcours complet. »

Section 6 : Conformité et sécurité

Ce que vous évaluez réellement : La posture de sécurité du fournisseur correspond-elle à votre exposition réglementaire — et peut-il le prouver par des certifications, et non par de simples assurances ?

Les questions de sécurité dans les RFP ont tendance à se transformer en une liste d'acronymes : SOC 2, ISO 27001, GDPR, HIPAA. Elles sont importantes, mais elles constituent un minimum requis pour tout fournisseur sérieux en 2026. Les questions qui différencient réellement les fournisseurs portent sur l'architecture — où vos documents résident pendant le traitement, s'ils sont utilisés pour l'entraînement des modèles, et qui y a accès.

Questions qui révèlent les choix d'architecture :

« Les documents téléversés sont-ils utilisés pour entraîner ou améliorer vos modèles d'IA ? Si oui, est-ce opt-in, opt-out ou obligatoire ? Précisez par niveau de déploiement. »
« Décrivez votre politique de conservation des données. Une fois l'extraction terminée, combien de temps nos documents restent-ils sur vos serveurs ? Pouvons-nous configurer une suppression automatique ? »
« Pour les secteurs réglementés : prenez-vous en charge les exigences de résidence des données (par exemple, traitement exclusivement dans l'UE pour le GDPR, traitement dans le pays pour certaines juridictions) ? Si ce n'est pas disponible aujourd'hui, quelle est votre feuille de route ? »
« Fournissez votre rapport SOC 2 Type II le plus récent, votre certificat ISO 27001 et un résumé de vos tests d'intrusion. Si ces rapports sont couverts par un NDA, décrivez le processus pour les partager. »

À ne pas demander : « Prenez-vous la sécurité au sérieux ? » La réponse est toujours oui.

À demander : « Nos documents sont-ils utilisés pour entraîner vos modèles ? Où résident-ils ? Combien de temps ? Qui peut les consulter ? »

Section 7 : Modèle de tarification

Ce que vous évaluez réellement : La tarification du fournisseur est-elle alignée sur votre usage réel de l'extraction de documents — ou crée-t-elle des incitations perverses ?

En 2026, la tarification de l'extraction de documents s'étend sur trois ordres de grandeur — de $0.01 par page sur les API cloud à plus de $200,000 pour des contrats d'entreprise annuels. Le prix affiché est rarement le prix réel. Les modèles de tarification diffèrent de manières qui peuvent multiplier silencieusement votre coût si votre profil d'usage ne correspond pas aux hypothèses du fournisseur. Pour une vue complète du paysage tarifaire actuel tous niveaux confondus, consultez notre analyse des tarifs d'extraction de documents 2026.

Questions qui révèlent le coût réel :

« Fournissez le coût annuel total pour notre volume prévu de [N] documents par mois, détaillé par : abonnement de base ou frais de plateforme, frais de traitement par document, tarifs de dépassement au-delà des limites du forfait, frais par utilisateur ou par siège, frais d'intégration ou de connecteur, coûts de mise en œuvre ou d'onboarding, et toute pénalité de engagement minimum. »
« Si nous traitons un document et que l'extraction échoue ou nécessite une correction manuelle, ce document est-il décompté de la limite de notre forfait ? Payons-nous les extractions échouées ? »
« Si notre volume double l'année prochaine, notre coût par document diminue-t-il, reste-t-il stable ou augmente-t-il ? Fournissez la courbe de prix à l'échelle pour des volumes de [actuel] / [2x] / [5x] documents par mois. »

Ne demandez pas : « Quel est votre tarif ? » Vous obtiendrez un prix de départ qui exclut la majeure partie de ce que vous paierez réellement.

Demandez plutôt : « Voici notre volume. Donnez-nous le coût annuel total ligne par ligne. Donnez-nous le coût à 2x et 5x notre volume actuel. »

Le piège qui fait couler la plupart des RFP : listes de fonctionnalités vs exigences métier

Tout mauvais RFP partage le même ADN. Il ressemble à ceci :

Fonctionnalité	Fournisseur A	Fournisseur B	Fournisseur C
Prend en charge le PDF	Oui	Oui	Oui
Prend en charge le JPG/PNG	Oui	Oui	Oui
Exporte vers Excel	Oui	Oui	Oui
Exporte vers CSV	Oui	Oui	Oui
Traitement par lots	Oui	Oui	Oui
Accès API	Oui	Oui	Oui

Une liste comme celle-ci produit une égalité à trois sur chaque ligne. C'est l'équivalent en approvisionnement de demander à des concessionnaires automobiles « vos voitures ont-elles des roues ? » — toutes les réponses sont oui, et vous n'avez rien appris.

Une liste de fonctionnalités demande « que peut faire votre outil ? ». Une exigence métier demande « voici ce que nous devons obtenir — montrez-nous comment votre outil y parvient ». La distinction n'est pas sémantique. Elle détermine si votre RFP produit une décision ou une pile de propositions identiques.

Pour chaque ligne de votre RFP, appliquez le test du « et alors » : si tous les fournisseurs répondent de la même manière, la question ne fait pas son travail. Remplacez-la par une question qui force la divergence.

Liste de fonctionnalités (inutile)	Besoin métier (utile)
« Prenez-vous en charge l'extraction PDF ? »	« Nos factures arrivent sous forme de PDF scannés à 150 DPI avec des notes manuscrites dans la marge. Extrayez ces 3 documents d'exemple et montrez-nous les résultats champ par champ. »
« Exportez-vous vers Excel ? »	« Notre équipe comptable a besoin des données extraites dans un fichier Excel où chaque ligne correspond à un document et chaque colonne à un champ extrait. Le fichier doit être généré sans mise en forme manuelle. Montrez-nous le résultat à partir de nos échantillons. »
« Prenez-vous en charge les documents multilingues ? »	« Nous recevons des factures en anglais, en allemand et en japonais — parfois au sein d'une même relation fournisseur. Extrayez ces 2 échantillons multilingues et montrez-nous comment les caractères non latins (kanji, trémas) sont traités. »
« Votre solution est-elle précise ? »	« Indiquez la précision et le rappel au niveau des champs sur nos 10 documents d'exemple. Pour tout champ dont la précision est inférieure à 90 %, expliquez la cause profonde et si votre système peut être configuré pour l'améliorer. »

Ce tableau mérite d'être imprimé et gardé à côté de votre clavier pendant que vous rédigez. Chaque fois que vous écrivez une question, demandez-vous : cela produira-t-il des réponses différentes selon les fournisseurs ? Si la réponse est non, reformulez-la jusqu'à ce que ce soit le cas.

Arrêtez de saisir les données à la main — laissez l'IA les lire pour vous

Importez une image ou un PDF — des données tabulaires structurées en 10 secondes

Essayez maintenant →

Notation des réponses : comment pondérer les critères sans se pénaliser

La notation est l'étape où même les RFP bien rédigés échouent. L'erreur la plus fréquente : pondérer chaque section de manière égale parce que cela semble équitable. Ce n'est pas équitable — c'est un refus de prioriser, et cela produit la même indécision qu'une liste de fonctionnalités.

Pondérez vos sections en fonction de ce qui déterminera réellement le succès ou l'échec de votre activité :

Section du RFP	Pondération suggérée	Règle d'ajustement
1. Réalité documentaire (résultats d'extraction sur échantillons)	30 %	Passez à 40 % si vos documents sont très variables (fournisseurs multiples, formats mixtes, écriture manuscrite). C'est la dimension décisive.
2. Exigences d'intégration	15 %	Passez à 25 % si vous avez une stack technique complexe (ERP + CRM + base de données personnalisée). Réduisez à 10 % si votre équipe travaille principalement dans des tableurs.
3. Exigences de précision	20 %	Passez à 30 % pour les secteurs réglementés ou les documents à enjeux élevés (contrats, rapports financiers). Ce score doit se fonder sur les résultats d'extraction réels sur échantillons, et non sur les affirmations des fournisseurs.
4. Évolutivité	10 %	Passez à 20 % si vous êtes en phase de croissance ou prévoyez d'ajouter des types de documents dans les 12 mois. Pour des volumes stables, 10 % suffisent.
5. Exigences opérationnelles	10 %	Passez à 20 % si vos utilisateurs ne sont pas techniques et connaissent un fort turnover. Pour les équipes disposant d'un support informatique dédié, 10 % suffisent.
6. Conformité et sécurité	10 %	Passez à 25 % pour la santé (HIPAA), la finance (SOC 2, GLBA) ou les contractants gouvernementaux. Pour les activités commerciales standard, 10 % suffisent.
7. Modèle de tarification	5 %	Cela peut sembler contre-intuitif — le prix ne devrait-il pas compter davantage ? Non. Le prix doit être un seuil, pas une dimension de notation. Fixez un plafond budgétaire avant d'émettre le RFP et éliminez tout fournisseur qui le dépasse. Parmi ceux qui passent, notez sur la capacité, pas sur l'écart de prix. Économiser 200 $/mois sur le mauvais outil coûte bien plus cher en temps de correction manuelle.

Ces pondérations reflètent une réalité que la plupart des processus d'achat refusent d'admettre : le fournisseur qui extrait vos documents réels avec le plus de précision est presque toujours le bon fournisseur, même s'il n'est ni le moins cher ni le plus complet en fonctionnalités. Tout le reste — intégrations, conformité, ergonomie — peut être contourné. La précision d'extraction est le fondement. Si elle est mauvaise, rien d'autre n'a d'importance.

Que faire une fois les réponses reçues

Vous avez envoyé la RFP. Vous avez reçu les propositions. Voici maintenant l'étape que la plupart des guides passent sous silence.

1. Évaluez d'abord les résultats d'extraction sur les échantillons, de manière isolée. Avant de lire le moindre argumentaire marketing, ouvrez le résultat d'extraction de chaque fournisseur pour vos 10 documents échantillons. Comptez les champs corrects. Comptez les erreurs. Classez les fournisseurs selon la précision au niveau des champs. C'est votre référence — tout le reste n'est qu'un commentaire sur ce chiffre.

2. Éliminez tout fournisseur qui n'a pas répondu à la question posée. Si vous avez demandé « montrez-nous le résultat extrait pour l'échantillon n° 4 » et que le fournisseur décrit à la place son moteur d'extraction en trois paragraphes, éliminez-le. Des réponses vagues à des questions précises pendant la RFP annoncent un support vague pendant l'implémentation. La RFP est un galop d'essai de la relation avec le fournisseur — traitez-la comme tel.

3. Présélectionnez deux fournisseurs pour un essai structuré. Ne prenez pas de décision finale sur la seule base d'une RFP. Retenez les deux meilleurs scores et lancez un essai d'une semaine avec votre équipe réelle traitant vos documents réels. La RFP vous fait passer de dix candidats à deux. L'essai vous fait passer de deux à un.

4. Vérifiez les références auprès d'entreprises ayant votre profil documentaire. Pas « n'importe quelle référence client fournie par le fournisseur ». Demandez spécifiquement une référence qui traite des documents similaires aux vôtres — même secteur, mêmes types de documents, volume comparable. Si le fournisseur ne peut pas en fournir une, c'est une information en soi.

FAQ

Quelle longueur doit avoir une RFP d'extraction de documents ?

5 à 10 pages de questions, plus votre annexe de documents échantillons. Si vous dépassez 15 pages, vous posez des questions qui ne permettront pas de différencier les fournisseurs. Les documents échantillons font plus de travail que dix pages de questions sur des listes de fonctionnalités.

À combien de fournisseurs dois-je envoyer la RFP ?

3 à 5. Moins de 3 et vous manquez d'une véritable base de comparaison. Plus de 5 et l'évaluation devient ingérable — vous vous rabattrez sur une notation superficielle car une analyse approfondie de 7 propositions ou plus prend des semaines. Présélectionnez les fournisseurs avant d'émettre la RFP : si un fournisseur ne prend pas en charge vos types de documents ou dépasse votre budget, ne l'incluez pas dans le processus formel.

Dois-je inclure mon budget dans la RFP ?

Oui. Deux raisons : premièrement, les fournisseurs largement au-dessus de votre fourchette s'auto-élimineront, ce qui vous fait gagner du temps d'évaluation. Deuxièmement, les fournisseurs dans votre fourchette peuvent adapter leur proposition à ce que vous pouvez réellement vous permettre plutôt que de deviner. La crainte que « les fournisseurs facturent exactement notre budget » coûte moins cher que de recevoir cinq propositions toutes à 3 fois ce que vous pouvez dépenser.

Ai-je besoin d'une RFP différente pour différents types de documents ?

Pas nécessairement une RFP différente, mais des ensembles de documents échantillons différents. La structure de la RFP reste la même — ce qui change, c'est l'annexe A (les documents). Si vous évaluez des outils à la fois pour le traitement de factures et l'extraction de contrats, incluez 5 échantillons de factures et 5 échantillons de contrats dans la même RFP. Notez-les séparément. Un fournisseur excellent sur les factures mais en difficulté sur les contrats vous dit quelque chose qu'un score global masquerait.

Que faire si un fournisseur refuse d'extraire nos documents d'exemple pendant la phase RFP ?

Cela arrive, surtout avec les fournisseurs d'entreprise qui exigent un NDA signé, un appel de découverte et un accord de preuve de concept avant de toucher à de vrais documents. Vous avez deux options : vous adapter à leur processus s'ils sont clairement les mieux adaptés pour d'autres raisons, ou les éliminer. Notre recommandation : éliminez-les. Un fournisseur incapable de démontrer sa capacité sur vos documents avant le contrat est un fournisseur qui ne veut pas être évalué sur vos documents. Les outils capables de faire le travail sont généralement prêts à le prouver.

À quelle fréquence devons-nous mettre à jour notre modèle de RFP ?

Révisez et mettez à jour vos questions de RFP après chaque cycle d'approvisionnement. Les questions qui n'ont pas produit de différenciation, les sections où tous les fournisseurs ont obtenu le même score, les critères qui se sont révélés sans importance lors de la mise en œuvre — celles-ci doivent être remplacées ou supprimées. Une RFP est un document vivant. Le modèle que vous utilisez pour votre troisième achat d'outil devrait être nettement meilleur que celui utilisé pour le premier.

Annexe : Téléchargement du modèle de RFP

La structure en 7 sections décrite dans cet article est conçue comme un point de départ — pas comme un formulaire à remplir. La réalité documentaire de chaque organisation est différente, et les questions les plus précieuses de votre RFP seront celles spécifiques à votre activité.

Un modèle de RFP téléchargeable basé sur le cadre de cet article est en préparation. Il inclura la structure complète en 7 sections avec des modèles de questions, le calculateur de pondération des scores et un guide de préparation des documents d'exemple. Revenez plus tard ou contactez-nous pour connaître sa disponibilité.

En attendant, voici un point de départ autonome : ouvrez un document vierge, intitulez-le « Cahier des charges logiciel d'extraction de documents — [Nom de votre entreprise] », et créez sept en-têtes de section correspondant à la structure ci-dessus. Sous chaque en-tête, écrivez une question sur votre activité à laquelle vous ne pouvez actuellement pas répondre sans demander à quelqu'un d'autre dans votre entreprise. Ces questions — celles qui nécessitent une discussion interne — constituent la véritable RFP. Les questions destinées aux fournisseurs en découlent.

La RFP qui produit le meilleur fournisseur n'est pas la plus longue ni la plus détaillée techniquement. C'est celle qui a été la plus difficile à rédiger — parce que la rédiger vous a forcé à comprendre votre propre activité avant de demander à quiconque de le faire.

L'outil d'extraction de documents adapté à votre activité n'est presque jamais celui qui possède le plus de fonctionnalités. C'est celui dont les forces correspondent à la manière spécifique dont vos documents sont désordonnés, dont votre équipe est structurée et dont vos systèmes en aval attendent les données. Une RFP est l'outil qui trouve cette correspondance — si vous la rédigez pour tester l'adéquation, et non pour recueillir des réponses par oui ou non.

Comment rédiger un RFP pour un logiciel d'extraction de documentsqui obtient de vraies réponses

Points clés