Qu’est-ce qu’un audit de faisabilité Data & SI ?
Un audit de faisabilité Data & Système d’Information (SI) vérifie que les conditions techniques d’un projet d’intelligence artificielle (IA) sont réunies : les données existent, leur qualité est suffisante, les accès sont autorisés et l’intégration aux applications métiers est possible.
Il distingue deux niveaux souvent confondus : la faisabilité locale — obtenir un résultat convaincant sur un échantillon — et la faisabilité systémique — faire fonctionner l’usage dans le flux réel, avec ses volumes, ses droits et ses contraintes d’exploitation.
Indiquez-nous les applications concernées, les données visées et les contraintes de sécurité à respecter.
Auditer la faisabilité de votre projet→Que faut-il vérifier avant d’engager un développement ?
- 01
Disponibilité et fraîcheur des données
L’information nécessaire existe-t-elle, à quel endroit, sous quelle forme, et est-elle à jour au moment où l’usage en a besoin ?
- 02
Qualité et cohérence
Doublons, référentiels concurrents, champs libres, historiques incomplets : ce que le modèle recevra réellement en entrée.
- 03
Droits d’accès et sécurité
Qui a le droit de voir quoi, comment ces droits se transposent dans l’usage IA et quelles données ne peuvent pas circuler.
- 04
Intégration applicative
Interfaces disponibles sur l’ERP, le CRM ou les outils métiers, capacités d’extraction, limites techniques et contraintes d’éditeur.
Pourquoi un démonstrateur réussi ne prouve-t-il pas la faisabilité ?
Un prototype travaille sur un échantillon choisi, préparé à la main, sans contrainte de droits ni de volume. C’est ce décalage qui explique une grande partie des projets abandonnés au moment de l’intégration.
La faisabilité locale se démontre vite : on extrait quelques centaines de documents propres, on obtient un résultat convaincant et la démonstration emporte l’adhésion. La faisabilité systémique pose d’autres questions. D’où viendront les données en production, à quelle fréquence, avec quel délai de mise à disposition ? Que se passe-t-il lorsque le champ est vide, le format inattendu ou l’historique incomplet ? Qui corrige, et selon quelle règle ?
Viennent ensuite les droits. Un utilisateur ne doit pas obtenir, par l’intermédiaire d’un assistant, une information à laquelle son profil n’a pas accès dans l’application d’origine. Reproduire cette logique d’habilitation dans une architecture de recherche documentaire ou d’agent représente souvent une part significative de l’effort, rarement anticipée dans les devis initiaux.
La circulation des données constitue le troisième point de contrôle. Selon leur nature — données personnelles, données de production, informations contractuelles — l’hébergement, les conditions du fournisseur et les obligations issues du Règlement général sur la protection des données (RGPD) orientent l’architecture retenue. Ces contraintes sont qualifiées avant de comparer une interface de programmation hébergée, une solution souveraine ou un modèle exécuté sur votre infrastructure. Elles ne se règlent pas après la signature.
Comment se déroule l’audit ?
- 01
Partir du besoin qualifié
Reprendre le processus, les entrants et les critères de succès définis pour savoir quelles données examiner.
- 02
Inspecter les sources
Examiner un échantillon réel : complétude, formats, doublons, fraîcheur, volumétrie et règles de gestion appliquées.
- 03
Éprouver les accès
Vérifier les interfaces disponibles, les droits, les modalités d’extraction et les limites imposées par les éditeurs.
- 04
Poser l’architecture cible
Décrire les composants, les flux, les habilitations, l’hébergement et les points de supervision nécessaires.
Ce que l’audit change dans la discussion avec les prestataires
Une entreprise qui connaît l’état de ses données et de ses interfaces ne reçoit pas les mêmes propositions. Les zones d’incertitude, qui se traduisent habituellement par des provisions ou des avenants, sont documentées à l’avance et deviennent des points de comparaison entre offres plutôt que des surprises en cours de réalisation.
L’audit précise aussi ce qui reste à la charge de l’entreprise. Nettoyer un référentiel, ouvrir un accès, faire évoluer un export, obtenir une autorisation auprès d’un éditeur : ces tâches n’apparaissent pas dans un devis de développement mais conditionnent le calendrier. Les rendre visibles évite qu’un projet soit déclaré en retard pour des raisons qui ne dépendent pas du prestataire.
Nous n’avons aucun intérêt à conclure dans un sens ou dans l’autre : nous ne vendons ni licences, ni infrastructure, ni forfait de développement lié à un éditeur. Lorsque les verrous techniques sont trop nombreux, nous le disons, et le budget est préservé pour le chantier qui débloquera réellement la situation.
Quels livrables recevez-vous ?
Une base technique opposable
Le niveau de détail dépend des accès accordés, de l’outillage disponible et de la coopération des éditeurs concernés.
