Logiciel, configuration ou développement sur mesure : quelle solution IA choisir pour les appels d’offres ?

01Le besoin et les données éliminent des options avant toute comparaison fonctionnelle

Choisir une solution d’intelligence artificielle pour répondre aux appels d’offres ne consiste pas à désigner celle qui produit la démonstration la plus impressionnante. La décision engage la manière dont les dossiers seront traités, les applications auxquelles la fonction devra se connecter, les informations qui pourront lui être confiées et les personnes capables de maintenir son fonctionnement. Une réponse convaincante sur quelques documents préparés peut devenir inutilisable face aux droits d’accès, aux formats irréguliers ou aux exigences de contrôle du travail réel.

Quatre voies doivent être distinguées. Une fonction peut être déjà intégrée au logiciel métier. Un produit existant peut être configuré selon le processus. Plusieurs composants peuvent être assemblés autour d’un besoin précis. Un développement spécifique peut enfin donner à l’entreprise une maîtrise plus étendue. Ces voies ne représentent pas quatre degrés universels de qualité. Elles répartissent différemment la responsabilité entre l’éditeur, le prestataire et l’entreprise.

La CNIL documente plusieurs possibilités, dont le système disponible sur étagère, le recours à un modèle propre, l’apport de connaissances par recherche, l’ajustement d’un modèle et différents modes d’hébergement.^[3] France Num recommande aux TPE et PME de rattacher l’adoption de l’intelligence artificielle à un besoin réel, à une organisation capable de l’exploiter et à des résultats que les utilisateurs peuvent contrôler.^[2] Cette diversité impose une comparaison centrée sur les responsabilités et les prérequis, au-delà des listes de fonctions.

Le bon arbitrage commence donc par des exclusions. Une voie disparaît si elle ne respecte pas une contrainte décisive. Les options encore recevables sont ensuite comparées selon le contrôle, l’intégration, le délai d’obtention d’une version testable et la charge de maintien. Cette séquence évite de récompenser une richesse fonctionnelle sans rapport avec le processus étudié.

Le premier travail consiste à décrire la décision ou la production que l’intelligence artificielle doit faciliter. Pour une réponse à appel d’offres, vouloir gagner du temps ou automatiser la rédaction reste trop vague. Il faut nommer l’opération concernée, son entrée, sa sortie, la personne qui la vérifie et la conséquence d’une erreur.

Une fonction d’analyse documentaire, une aide à la qualification et une assistance à la rédaction ne sollicitent pas les mêmes informations. Elles ne produisent pas non plus les mêmes risques. Une synthèse destinée à orienter une première lecture n’a pas le même statut qu’un passage incorporé dans une offre remise à l’acheteur. Dans le second cas, une erreur peut modifier un engagement, omettre une exigence ou introduire une incohérence entre plusieurs pièces.

Le choix doit partir du besoin concret, de la sensibilité de l’usage, des données d’entrée et du niveau de risque. La CNIL recommande de définir le besoin, les usages admis, les données concernées et les garanties attendues avant le choix d’un système.^[3] Elle demande aussi d’associer les parties prenantes et de fixer les usages autorisés ou interdits.^[10] Ces deux références soutiennent une règle simple : une option incompatible avec le contexte ne devient pas acceptable grâce à une sortie mieux rédigée.

La sensibilité des entrées doit être distinguée de la sensibilité de la sortie. Un dossier peut contenir des données personnelles, des informations financières, des méthodes internes ou des éléments communiqués sous une obligation de confidentialité. La proposition produite peut, de son côté, rester un brouillon interne ou devenir un engagement destiné à l’acheteur. Le choix de la voie doit tenir compte de ces deux dimensions.

Le degré d’automatisation modifie encore l’analyse. Une proposition que le collaborateur relit intégralement ne crée pas la même dépendance qu’un contenu transféré automatiquement vers un dossier. Le contrôle humain ne peut pas rester une promesse générale. Il faut déterminer qui vérifie, à quel moment, avec quelles informations et selon quels critères.

Les contraintes non négociables

Quatre familles suffisent à faire apparaître les premières incompatibilités. L’intégration indique les applications, les droits et les formats nécessaires. Les données précisent ce qui peut être transmis, conservé ou réutilisé. Le contrôle désigne les validations humaines obligatoires. Les compétences révèlent qui saura configurer, tester, surveiller et corriger la fonction.

Une contrainte n’est éliminatoire que si elle est formulée de manière vérifiable. Dire que la sécurité est importante n’oriente aucune décision. Exiger qu’une catégorie de documents ne quitte pas un environnement autorisé permet d’écarter un mode de déploiement. Demander une intégration parfaite reste abstrait. Nommer l’application, l’action attendue et le droit nécessaire rend l’exigence testable.

La recherche et l’analyse documentaire peuvent servir à classer, extraire, retrouver ou synthétiser des informations issues de documents textuels ou structurés.^[8] Ces possibilités générales ne décrivent pourtant pas la sortie attendue. Elles doivent être ramenées à une opération précise, faute de quoi plusieurs voies paraîtront équivalentes alors qu’elles ne traiteront pas le même travail.

L’incertitude doit rester visible. Si l’entreprise ignore encore quelles données sont admises, qui valide les sorties ou quelle application doit recevoir le résultat, la contrainte n’est pas satisfaite. Elle est inconnue. Cette distinction empêche de transformer une absence d’information en accord implicite.

02Quatre voies engagent quatre répartitions différentes des responsabilités

Les quatre voies ne se distinguent pas uniquement par leur degré de personnalisation. Chacune place la maîtrise à un endroit différent. Avec une fonction intégrée, l’éditeur décide largement du rythme d’évolution, de l’interface et des possibilités techniques. Une configuration déplace une partie des réglages vers l’entreprise ou son prestataire. Un assemblage ajoute des responsabilités d’intégration. Un développement spécifique étend encore le contrôle et la charge assumée.

Les options documentées comprennent l’outil sur étagère, le modèle propre, le RAG, l’ajustement et plusieurs modes d’hébergement. Cette typologie fournie par la CNIL montre qu’un choix peut combiner un produit, un modèle, un mécanisme d’apport de connaissances et un mode de déploiement.^[3] Elle ne crée pas une hiérarchie automatique entre les options.

La fonction intégrée convient lorsque le besoin se trouve déjà couvert dans l’environnement de travail, que les données admises sont compatibles avec les conditions d’utilisation et que les sorties restent contrôlables. La configuration devient pertinente lorsqu’un produit existant possède les composants nécessaires, mais doit être réglé selon les rôles, les étapes ou les formats de l’entreprise.

L’assemblage sur mesure relie des briques existantes afin de répondre à un processus plus particulier. Il peut associer une interface, des règles, des connexions et un mécanisme de génération. Le développement spécifique va plus loin lorsque l’entreprise doit maîtriser une logique que les produits disponibles ne reproduisent pas dans des conditions acceptables.

La frontière entre configuration, assemblage et développement n’est pas toujours commerciale. Un fournisseur peut présenter comme standard une fonction qui exige en réalité des connexions particulières. Un autre peut qualifier de sur-mesure un paramétrage largement prévu par son produit. La comparaison doit donc porter sur les actes à accomplir et sur leur responsable.

La responsabilité derrière l’étiquette

Une comparaison sérieuse attribue quatre verbes : configurer, héberger, tester et corriger. Pour chaque voie, il faut savoir qui accomplit chaque action, avec quels moyens et dans quel délai. Il faut aussi prévoir ce qui se passe si cette personne ou ce fournisseur n’est plus disponible.

Avec une fonction intégrée, l’entreprise configure généralement un périmètre prévu par l’éditeur et dépend de ses corrections. Avec un outil configurable, elle assume davantage de règles, d’accès et d’essais. Avec un assemblage, elle doit aussi maintenir les connexions entre composants. Avec un développement spécifique, elle devient responsable de choix techniques plus nombreux, même si leur réalisation est confiée à un partenaire.

La maîtrise ne se mesure pas au nombre de réglages visibles. Elle se mesure à la capacité d’expliquer le fonctionnement, de reproduire un essai, d’identifier l’origine d’un défaut et d’obtenir une correction dans un délai compatible avec l’activité. Une voie apporte du contrôle seulement si les responsabilités correspondantes sont réellement couvertes.

La dépendance fournisseur n’est pas toujours un défaut. Elle peut être préférable à une autonomie théorique que l’entreprise n’a pas les compétences pour assumer. La question utile est de savoir si cette dépendance est comprise, contractuellement encadrée et compatible avec la criticité du processus.

03Une fonction déjà intégrée limite les changements d’habitudes sans résoudre tous les écarts métier

Une fonction présente dans le logiciel déjà utilisé mérite d’être examinée en premier lorsque le besoin est fréquent et proche du fonctionnement prévu par l’éditeur. Elle réduit les changements d’interface, les demandes d’accès et le nombre de composants à connecter. Elle peut aussi diminuer le travail initial de déploiement. Ces avantages sont concrets, mais ils ne prouvent pas que la fonction traite correctement chaque étape du processus.

Des fonctions déjà intégrées aux logiciels métier peuvent limiter l’investissement et la rupture d’usage, sans prouver qu’elles conviennent à toute entreprise. Le retour d’expérience publié par France Num sur une PME du bâtiment décrit l’analyse de cahiers des charges, la préparation d’une première structure de réponse et une relecture humaine systématique.^[1] Ce cas établit l’intérêt opérationnel d’une assistance insérée dans un processus connu, pas son adéquation universelle.

L’écart métier apparaît souvent dans les détails. La fonction peut reconnaître un document sans produire la synthèse attendue. Elle peut rédiger un passage sans respecter les catégories utilisées par l’entreprise. Elle peut être accessible dans le bon logiciel, mais ignorer une information stockée ailleurs. L’intégration visible dans l’interface ne garantit donc ni la couverture du processus ni l’accès aux bonnes données.

Son intégration ne dispense pas de rattacher le projet à un besoin, à une organisation et à des résultats contrôlables.^[2] Une fonction intégrée doit être confrontée à cette diversité réelle. Un résultat satisfaisant sur un document simple ne suffit pas si les exceptions sont précisément celles qui déterminent la recevabilité ou l’engagement de l’entreprise.

Une interface familière ne prouve pas que la fonction convient

L’évaluation doit porter sur un cas représentatif, avec les formats et les contraintes réellement rencontrés. Il faut observer la qualité de la sortie, mais aussi le temps de vérification, la possibilité de retrouver l’information d’origine et la facilité avec laquelle un collaborateur corrige la proposition. Une sortie élégante qui demande une relecture plus longue que le travail initial n’apporte pas l’avantage recherché.

La fonction intégrée reste une bonne candidate si elle couvre le noyau du besoin sans contournement fragile. Elle doit être écartée ou complétée lorsque les utilisateurs exportent manuellement des données, recopient les résultats entre plusieurs applications ou reconstruisent systématiquement la sortie. Ces gestes signalent que la continuité d’interface masque une rupture de processus.

La décision ne consiste pas à exiger une couverture totale. Elle consiste à vérifier que les écarts restants sont connus, acceptables et correctement attribués. Une fonction intégrée peut traiter une première lecture pendant qu’une validation humaine conserve l’interprétation et l’engagement final. Elle cesse de suffire lorsque l’étape manquante porte précisément la valeur ou le risque du processus.

La qualité de l’adoption dépend enfin de la lisibilité des limites. Une fonction modeste, dont les utilisateurs comprennent le rôle, peut être mieux exploitée qu’une fonction étendue présentée comme autonome. L’entreprise doit pouvoir expliquer ce que le système prépare, ce qu’il ne vérifie pas et quelle personne reste responsable de la décision.

04Le développement sur mesure commence par un référent métier et un protocole d’essai

Un assemblage ou un développement spécifique devient pertinent lorsqu’un écart métier important ne peut pas être traité par une configuration raisonnable. La personnalisation n’est toutefois pas une qualité en soi. Chaque adaptation ajoute une décision à documenter, une fonction à tester et une responsabilité à maintenir. Sans référent métier, le projet risque de reproduire une représentation simplifiée du travail.

Un assemblage sur mesure exige un référent métier, un partenaire compétent et des essais rigoureux sur le processus visé. France Num décrit un retour d’expérience dans lequel ces rôles encadrent un pilote consacré à l’analyse d’appels d’offres et à une fiche de synthèse destinée à la décision.^[7] Le cas montre que le sur-mesure repose sur une méthode de vérification avant d’envisager l’accumulation de composants.

Le référent métier ne se contente pas de valider une démonstration. Il décrit les entrées, les exceptions, les sorties acceptables et les erreurs qui imposent un arrêt. Il choisit les cas d’essai et explique pourquoi ils représentent le processus. Il distingue aussi les règles stables des situations qui réclament le jugement d’un collaborateur.

Le partenaire technique doit transformer ces attentes en éléments observables. Une connexion répond à un besoin d’accès déterminé. Une règle traite un écart identifié. Une interface rend une validation possible. Si une adaptation ne peut pas être reliée à une attente précise, elle augmente la complexité sans améliorer la décision.

La personnalisation qui reste testable

Une adaptation testable se rattache à une attente observable. Si la fonction doit repérer une exigence, l’essai indique comment reconnaître sa présence et vérifier la référence. Si elle doit produire une synthèse, le protocole précise les rubriques attendues, les omissions graves et la personne qui tranche les cas ambigus.

Le jeu d’essai doit comporter des dossiers ordinaires, des formats moins propres et des situations susceptibles de provoquer une erreur. Un essai composé uniquement de documents préparés pour la démonstration mesure la qualité de la présentation, pas la résistance du fonctionnement. Les mêmes entrées doivent pouvoir être rejouées après un changement de modèle, de règle ou de connexion.

Les résultats ne se résument pas à un taux moyen. Une erreur rare peut rester inacceptable si elle porte sur une exigence éliminatoire ou un engagement contractuel. Le protocole doit donc classer les défauts selon leur conséquence, préciser la correction attendue et dire qui autorise la reprise des essais.

Le diagnostic doit rester possible. Il faut pouvoir distinguer un défaut d’accès, une mauvaise extraction, une règle inadaptée et une génération erronée. Si toutes les anomalies produisent une réponse opaque, l’entreprise ne possède pas une fonction maintenable, même lorsque la moyenne des résultats paraît satisfaisante.

1. 01

   Décrire la sortie

   Le référent métier nomme le document, la décision ou l’action à obtenir, avec ses critères de vérification.

2. 02

   Choisir les cas d’essai

   Une adaptation testable relie chaque modification à un écart métier et à un résultat observable.^[7]

3. 03

   Couvrir les exceptions

   Les dossiers retenus représentent le fonctionnement courant, les formats difficiles et les erreurs lourdes de conséquences.

4. 04

   Rejouer les essais

   Les mêmes entrées sont utilisées après chaque modification afin de comparer les résultats.

5. 05

   Attribuer la correction

   Le protocole indique qui examine le défaut, qui décide de la correction et qui autorise la reprise.

05Une démonstration réussie ne dit rien de la maintenance à douze mois

La mise en service constitue un passage, pas une preuve de durabilité. Une fonction peut réussir avec un nombre réduit de dossiers, des droits préparés et un interlocuteur technique immédiatement disponible. Plusieurs mois plus tard, les formats ont changé, des comptes ont été supprimés, une application connectée a évolué ou les utilisateurs ont adopté des pratiques qui n’étaient pas prévues.

La maintenabilité désigne la capacité à comprendre, surveiller et corriger le fonctionnement dans la durée. Elle repose sur une documentation exploitable, des essais reproductibles, des responsabilités attribuées et des compétences disponibles. Elle doit être évaluée avant la sélection, car une architecture qui dépasse durablement les capacités de l’entreprise crée une fragilité prévisible.

La documentation utile ne se résume pas à une description technique. Elle explique les usages admis, les dépendances, les règles de contrôle, les cas d’essai et la conduite à tenir lorsqu’une anomalie apparaît. Une personne compétente doit pouvoir déterminer si le problème vient des données, d’une connexion, d’une configuration ou du comportement du modèle.

La surveillance ne doit pas devenir une collecte indifférenciée. Elle doit porter sur les événements nécessaires à la maîtrise du service, dans le respect des règles applicables aux données. Son but est de détecter une dégradation, de comprendre un incident et de décider si la fonction peut continuer à être utilisée.

La charge après la mise en service

Trois questions rendent la charge visible. Qui vérifie régulièrement que les essais de référence passent encore ? Qui intervient lorsqu’une connexion ou un droit d’accès change ? Qui décide qu’un défaut impose de suspendre une fonction ? Si les réponses désignent seulement le prestataire sans délai, procédure ni possibilité de reprise, la dépendance reste entière.

Une fonction intégrée transfère une part de la maintenance à l’éditeur, mais l’entreprise doit encore surveiller son adéquation à l’usage. Une configuration exige de conserver ses réglages et ses essais. Un assemblage ajoute la surveillance des interfaces. Un développement spécifique demande une capacité durable de diagnostic et de correction.

Les compétences doivent être appréciées au-delà de l’équipe projet. La personne qui a construit la première version peut quitter l’entreprise ou ne plus être disponible. La documentation, les droits administratifs, les procédures d’essai et les modalités d’assistance doivent rendre la continuité possible sans dépendre d’une mémoire individuelle.

Une voie moins souple peut être préférable si elle reste compréhensible et réparable par les personnes disponibles. Une voie plus ambitieuse devient raisonnable seulement lorsque l’entreprise accepte les responsabilités correspondantes. La qualité initiale ne doit donc jamais masquer le coût organisationnel de la continuité.

La durabilité se juge sur ce qui demeure vérifiable après le départ de l’équipe projet.^[6][9]

06Les données sensibles rendent le contrat aussi décisif que l’architecture

Une option fonctionnellement convaincante peut être éliminée par son mode de déploiement ou par son contrat. Cette conclusion vaut dès que le processus utilise des données personnelles, confidentielles ou stratégiques. L’emplacement annoncé du service ne suffit pas. Il faut examiner les flux, les accès, la conservation, la réutilisation éventuelle et les responsabilités du fournisseur.

Le mode de déploiement et le contrat fournisseur doivent être examinés lorsque des données personnelles, confidentielles ou stratégiques sont traitées. La CNIL recommande de vérifier les garanties contractuelles, les usages des données et les conditions de déploiement avant l’utilisation d’un système d’intelligence artificielle générative.^[3] L’ANSSI traite la sécurité depuis la conception jusqu’au déploiement et à l’utilisation en production.^[4]

Une offre hébergée peut fournir des garanties suffisantes dans un contexte et rester incompatible avec un autre. Une installation contrôlée par l’entreprise peut réduire certains transferts sans résoudre automatiquement la gestion des accès, la mise à jour ou la conformité. Le mot local ne remplace donc ni l’analyse des flux ni l’attribution des responsabilités.

La gestion des identités et des accès précise qui peut atteindre une ressource, avec quel rôle et quelle traçabilité.^[5] Elle devient déterminante lorsque plusieurs équipes, filiales ou prestataires interviennent dans la réponse aux appels d’offres. Un compte partagé ou un droit trop large peut annuler une partie des bénéfices attendus du déploiement choisi.

Le fournisseur n’est pas la seule source de risque. Les droits internes, les exports manuels, les journaux techniques ou les copies de travail peuvent créer des flux que le schéma d’architecture principal ne montre pas. Le contrôle doit suivre la donnée depuis son entrée jusqu’à sa suppression ou sa restitution.

Les clauses qui changent le choix

Le contrat doit indiquer ce que le fournisseur peut faire des données transmises, quels sous-traitants interviennent, où les traitements ont lieu et comment les données sont restituées ou supprimées. Il doit aussi préciser les engagements de sécurité, les conditions de modification du service, les modalités d’assistance et la répartition des responsabilités.

La réversibilité mérite une attention particulière. Si l’entreprise quitte le service, elle doit savoir ce qu’elle récupère : configurations, historiques autorisés, règles, journaux nécessaires, résultats ou documentation. Une dépendance peut être acceptable lorsqu’elle est comprise et compensée. Elle devient dangereuse lorsqu’aucune sortie exploitable n’est prévue.

Les évolutions du service doivent être examinées avec la même rigueur. Un changement de modèle, de sous-traitant, de lieu de traitement ou de conditions d’utilisation peut modifier l’acceptabilité de la voie. Le contrat doit permettre d’identifier ces changements et de décider si un nouvel essai ou un nouvel arbitrage est nécessaire.

L’examen contractuel doit intervenir avant la généralisation du test. Si une clause interdit l’usage envisagé ou laisse une réutilisation incompatible avec les informations confiées, la voie sort de la comparaison. Une meilleure notation fonctionnelle ne corrige pas cette incompatibilité.

07La matrice finale doit pouvoir conclure qu’aucune voie n’est encore prête

L’arbitrage final commence par les contraintes éliminatoires, puis compare les voies encore admissibles. Mélanger ces deux opérations dans une note globale crée un résultat trompeur. Une excellente intégration ou un délai court peut alors compenser artificiellement une incompatibilité sur les données, le contrat ou la capacité de maintenance.

La première partie de la matrice répond uniquement à la question de recevabilité. Chaque voie respecte-t-elle les contraintes de données, de contrôle, d’intégration et de compétences ? Une réponse négative élimine l’option. Une réponse inconnue ne vaut pas validation : elle déclenche une demande de preuve, une correction ou un report.

La seconde partie compare les options recevables. Le contrôle mesure la capacité à régler, expliquer et corriger le fonctionnement. L’intégration apprécie la continuité avec les applications et les droits existants. Le délai porte sur le temps nécessaire pour obtenir une version testable, pas sur une promesse commerciale. La maintenabilité examine la documentation, les essais, la surveillance et les compétences durables.^[6][9]

Cette matrice ne calcule pas un retour sur investissement général. Elle rend visible l’option qui correspond le mieux au processus et aux contraintes observées. Le poids de chaque critère dépend de la décision réelle. Une entreprise peut accepter moins de personnalisation pour réduire sa charge de maintien. Une autre peut accepter un délai supérieur si elle doit maîtriser une logique métier déterminante.

Une décision sans vainqueur forcé

Quatre issues doivent rester possibles. La voie peut être retenue telle quelle. Elle peut être retenue sous réserve d’une correction précise. Elle peut être comparée de nouveau après production d’une preuve manquante. Le projet peut enfin être différé si aucune voie ne couvre les prérequis.

Le report protège l’entreprise contre un choix prématuré. Une option prometteuse ne doit pas devenir une décision tant que personne ne sait qui la maintiendra, quelles données elle pourra recevoir ou comment un défaut sera corrigé. Une inconnue sur un critère éliminatoire appelle une preuve, pas une note moyenne.

La décision doit consigner les hypothèses qui la soutiennent. Un changement de contrat, de données, d’application connectée ou de compétence disponible peut modifier le classement. La matrice devient ainsi un support d’arbitrage révisable plutôt qu’un palmarès figé.

Lorsqu’un prérequis organisationnel reste incertain, un audit IA centré sur les usages et les responsabilités peut établir les contraintes à résoudre avant la sélection technique. Cette intervention ne remplace pas l’essai de la fonction. Elle évite de demander à un fournisseur de répondre à une question que l’entreprise n’a pas encore formulée.

Le bon choix est l’option recevable que l’entreprise pourra encore expliquer, tester, corriger et maintenir après la démonstration.^{[3][4][6][9][10]}