Quelles données et quels accès préparer avant un projet IA

Pourquoi les données et les accès bloquent souvent plus que la technique

Quand un projet IA prend du retard en entreprise ou collectivité, la cause technique est rarement en jeu. C’est presque toujours un sujet de données mal cartographiées ou d’accès non cadrés.

Quelques exemples typiques. Le projet attend parce que personne ne sait qui a la main sur la boîte mail partagée. La phase de tests cale parce que l’équipe découvre tardivement que les données du CRM contiennent des informations RGPD non identifiées au départ. La mise en production est repoussée parce que le compte d’accès créé pour l’IA a été configuré avec les droits admin par défaut, et qu’il faut le réduire avant d’ouvrir au-delà de l’équipe pilote.

Aucun de ces blocages n’est une fatalité. Tous se règlent en amont, avec une heure de préparation par sujet. La différence entre un projet livré rapidement et un projet qui s’étire se joue souvent à ce niveau, pas au niveau des modèles.

L’article qui suit donne la liste opérationnelle de ce qu’il faut préparer. Pour le cadre conceptuel sécurité et RGPD, voir sécurité, RGPD et IA : le cadre opérationnel.

Les données à préparer avant le projet

Quatre questions à se poser, processus par processus.

1. Quel est le processus cible exactement ?

Avant de parler données, on a besoin d’une fiche périmètre courte : « telle tâche, faite N fois par semaine, par X personnes, qui consomme Y heures ». Sans ce point de départ, la cartographie des données reste théorique. La méthode pour bien choisir le périmètre est dans comment choisir le premier processus à automatiser.

2. Quels outils sont concernés ?

Lister concrètement les outils qui interviennent dans le processus : CRM, ERP, outil de facturation, drive documentaire, boîte mail partagée, tableur Excel, base de données interne. Une liste à 1-3 outils est un bon premier projet. À 6 outils, ce n’est plus un premier projet, c’est une refonte.

3. Quelles données sont réellement utilisées ?

C’est la question la plus sous-estimée. Pour un même processus, l’équipe pense souvent utiliser « les fiches clients », alors qu’en réalité elle ne lit que 4 champs sur les 35 disponibles. L’IA n’a pas besoin de plus.

Le bon réflexe : lister les champs précis qui rentrent dans la décision (nom, email, montant, date, statut), pas les « tables » ou « objets » abstraits.

4. Quelle est la classification de ces données ?

Quatre catégories suffisent en pratique, du plus permissif au plus restreint :

• Données publiques : catalogue, FAQ, contenu site → aucune restriction
• Données opérationnelles : commandes, logs, statuts internes → anonymisation possible
• Données personnelles clients (RGPD) : nom, email, téléphone, adresse → cadre strict obligatoire
• Données stratégiques ou sensibles : finance, RH internes, secrets industriels → hébergement européen ou local

Faire ce classement avant le projet permet de choisir le bon niveau de stack technique sans bloquer en cours de route. Sur les périmètres sensibles, on bascule typiquement vers Mistral AI hébergé en Europe ou OVHcloud, plutôt que sur des services grand public sans DPA.

Les accès à cadrer avant le projet

Trois niveaux d’accès, chacun à border séparément.

Accès lecture

À quelles données l’IA doit-elle pouvoir accéder en lecture pour faire son travail ? La réponse honnête est presque toujours « moins que ce qu’on imagine au départ ».

Pour un projet de relances commerciales, l’IA a besoin de lire la liste des prospects, leurs derniers échanges et le statut de leur opportunité. Pas le pipeline complet de la société, pas les commissions des commerciaux, pas l’historique du compte client.

Accès écriture

À quoi l’IA peut-elle écrire, modifier ou envoyer ? C’est ici que la majorité des risques se concentrent.

Cas typiques :

• Écriture dans le CRM : créer une note ? mettre à jour un statut ? modifier une fiche client ?
• Envoi d’email : brouillon à valider par un humain ? envoi direct au client ?
• Modification de devis ou facture : générer un brouillon ? modifier un document existant ?
• Ressaisie comptable : alimenter un journal de saisie ? modifier des écritures validées ?

La règle par défaut : brouillon avec validation humaine sur tout ce qui sort vers un client ou impacte une donnée financière. Envoi direct uniquement quand la règle métier est totalement stable et que l’erreur est récupérable.

Accès API et comptes techniques

Pour qu’une automatisation tourne, il faut un accès technique aux outils concernés. Trois principes simples.

• Compte dédié, pas compte personnel : on ne fait jamais tourner une automatisation sur le compte d’un salarié. Si la personne quitte l’entreprise, l’automatisation casse. Et la traçabilité est inutilisable.
• Moindre privilège : ce compte technique a uniquement les droits dont il a besoin pour le processus cible. Pas plus. Surtout pas l’accès admin « pour aller plus vite ».
• Environnement de test vs production : la phase de tests doit pouvoir tourner sur un environnement isolé ou avec un périmètre données restreint. La bascule vers la production se fait après validation.

Pour les outils typiques d’une entreprise ou collectivité (CRM, ERP, drive documentaire, boîte mail partagée, outil de facturation), créer ces comptes dédiés prend 1 à 2 heures à un référent technique. C’est un investissement modeste qui évite des blocages majeurs en cours de projet.

Qui doit valider quoi en interne

Sans rôles clairs, le projet patine. Trois rôles à nommer avant le lancement.

Le décideur

Une seule personne. C’est elle qui arbitre en cas de désaccord sur le périmètre, qui valide la mise en production, qui décide d’élargir ou non. Sans décideur identifié, chaque décision passe par un comité, et le projet glisse.

Le référent métier

La personne qui connaît le processus dans le détail. Capable d’expliquer en 30 minutes ce qui se fait, comment, et avec quelles exceptions. Disponible 1 à 2 heures par semaine pendant la durée du projet, pas plus. C’est elle qui fournit les cas de test réels et qui valide les résultats fonctionnels.

Le référent technique

La personne qui a la main sur les outils concernés. C’est elle qui crée les comptes dédiés, qui ouvre les accès API, qui contrôle les flux. Pas besoin d’être un profil IA — un administrateur système ou un référent IT classique suffit.

Sur les sujets sensibles (données RGPD, accès financier, validation client), une validation humaine sur les actions critiques doit être prévue. Concrètement : qui signe les emails sortants ? qui valide les modifications dans le CRM ? qui supervise les premiers jours en production ? Ces réponses se figent au cadrage, pas au moment du déploiement.

Les erreurs les plus fréquentes à éviter

Cinq erreurs récurrentes, classées par fréquence observée.

1. Donner un accès admin « pour aller plus vite »

C’est la cause numéro un de risques en pratique. Le compte technique est créé avec les droits admin parce que personne n’a pris le temps de cibler les permissions exactes. Conséquence : un bug dans le prompt = un risque massif. Toujours créer un compte dédié avec scope minimal.

2. Découvrir le sujet RGPD en cours de projet

« Au fait, est-ce qu’on a le droit ? » posé tardivement est le plus court chemin vers un projet qui ne passe jamais en production. La classification des données et la base légale (consentement, intérêt légitime, obligation contractuelle) se font au cadrage, pas après.

3. Oublier le DPA quand on utilise un service tiers

Quand le processus utilise un service IA externe (Claude, OpenAI Enterprise, Mistral, etc.), un DPA (Data Processing Agreement) signé est nécessaire dès qu’on traite des données personnelles. C’est un document standard, mais il doit être en place avant la mise en production. Sans DPA, le service ne peut pas être utilisé en conformité RGPD.

4. Sauter la journalisation

Sans journal des actions critiques (qui a fait quoi, quand, sur quelle donnée), il devient impossible de comprendre ce qui s’est passé en cas d’incident. C’est aussi ce que demande la CNIL en cas de contrôle. La journalisation se met en place dès le déploiement initial, pas après le premier incident.

5. Confondre adoption et déploiement

Mettre l’outil à disposition n’est pas l’adopter. Sans formation des utilisateurs et sans suivi des premiers temps d’usage, l’outil reste inutilisé. Pour le détail du déploiement et de la formation, voir déployer un cas d’usage IA, étape par étape.

Pour le panorama complet des causes d’échec, l’article dédié est pourquoi les projets IA échouent et comment les éviter.

La checklist simple avant lancement

Dix points. Si les dix sont validés, le cadrage technique du projet va 3 fois plus vite.

1. Processus cible identifié : 1 flux précis, fréquent, mesurable
2. Outils concernés listés : 1 à 3 outils, pas plus pour un premier projet
3. Données utilisées cartographiées : champs précis, pas tables abstraites
4. Classification des données posée : public / opérationnel / personnel / sensible
5. Comptes dédiés créés : pas de compte personnel pour l’IA
6. Moindre privilège appliqué : permissions ciblées, pas d’admin par défaut
7. Validation humaine définie : qui valide quoi sur les actions critiques
8. DPA signé si service tiers utilisé sur données personnelles
9. Hébergement adapté : européen quand des données personnelles sont en jeu
10. Référents nommés : un décideur, un référent métier, un référent technique

Cette checklist se remplit en 1 à 2 heures côté client. C’est ce qu’on regarde au diagnostic gratuit chez Cohivia, en amont de la proposition.

Pour situer le coût d’un premier projet une fois cette préparation faite, voir combien coûte un premier projet d’IA et le calculateur ROI pour un ordre de grandeur sur votre cas.

Cas typiques où cette checklist se traduit concrètement :

• Traitement d’emails entrants : accès lecture sur la boîte partagée, écriture sur les brouillons, validation humaine avant envoi
• Relances commerciales : lecture pipeline, écriture des notes CRM, brouillons d’emails à valider par le commercial
• Support client : lecture de la base de connaissances, brouillons de réponse, escalade humaine sur les cas complexes
• Devis et factures : extraction d’informations clés, brouillons de documents, validation comptable obligatoire
• Onboarding RH : lecture des dossiers candidats, génération de documents, signature humaine maintenue
• Ressaisie CRM ou comptabilité : lecture sur outil source, écriture ciblée sur outil destination, journalisation systématique
• Recherche documentaire interne : lecture du drive, pas d’écriture, accès limité aux dossiers concernés

Pour voir comment ces flux se traduisent en projets concrets, nos réalisations montrent les patterns observés en RH, commercial, finance, support et opérations.

---

Vous voulez que ce cadrage soit fait sérieusement avant de lancer ? L’appel diagnostic permet de poser les 10 points en 30 minutes, gratuit, et de partir sur une base saine.