Un projet IA confié à un prestataire se pilote par jalons : cadrage signé, accès aux données ouverts dès la première semaine, prototype, version pilote, puis version de production, chacun validé par l’entreprise. La recette, ce contrôle qui précède l’acceptation, s’écrit avant le développement ; la reprise par vos équipes se prépare dès le contrat.
Avant de signer un projet IA : qui décide quoi
Le calendrier d’un projet IA commence avant le premier atelier avec le prestataire. Quatre décisions conditionnent la suite, chacune avec un titulaire identifiable dans l’entreprise. Une décision orpheline ne bloque pas le démarrage : elle bloque le premier jalon.
- L’objectif métier et le budget : la direction générale les arrête et tranche la poursuite à chaque étape.
- Le cas d’usage et les critères d’acceptation : le responsable du processus les rédige, puisqu’il signera la recette.
- L’hébergement, les accès et l’intégration au système d’information (SI) : la direction des systèmes d’information (DSI) les fixe.
- Le cadre juridique des données : le référent RGPD (règlement général sur la protection des données) qualifie le rôle de chacun.
Ce dernier point se règle par contrat. Dans sa fiche pratique d’avril 2024 sur la qualification des fournisseurs de systèmes d’IA, la Commission nationale de l’informatique et des libertés (CNIL) indique qu’un prestataire qui développe un système pour le compte d’un client peut être sous-traitant. Le traitement de vos données se limite alors à vos instructions, écrites dans un contrat de sous-traitance.
Votre statut au regard du règlement européen sur l’IA se tranche au même moment : selon l’usage prévu, vous agissez comme déployeur ou devenez fournisseur, comme le détaille l’article sur ce que l’AI Act impose à votre entreprise.
Listez enfin ce qui vous revient en fin de contrat : code, paramétrages, modèles ajustés, jeux de test, documentation. Le calendrier qui suit suppose aussi le cas d’usage arrêté ; sinon, les cas d’usage de l’IA générative en entreprise offrent des points de départ.
Le calendrier type, du cadrage à la mise en production
Un calendrier de projet d’intelligence artificielle se lit comme une suite de décisions, pas de tâches. Chaque phase livre un résultat que l’entreprise examine, puis appelle un choix : poursuivre, réorienter ou arrêter. Bout à bout, le parcours compte six jalons :
- le cadrage signé : périmètre, critères d’acceptation, contrat de sous-traitance ;
- les accès ouverts : données, comptes, environnements ;
- le prototype, présenté sur vos propres données ;
- la version pilote, utilisée par un groupe restreint en conditions réelles ;
- la version de production, après recette et audit de sécurité ;
- la reprise par vos équipes, documentation et contrat de maintenance en main.
Le calendrier proposé par une agence IA sérieuse suit cette logique de portes successives. La méthode que publie Digital Unicorn s’organise en quatre temps : audit et cadrage, conception et prototypage, développement et déploiement, puis suivi et amélioration continue. Rapportés à votre calendrier, ces quatre temps donnent des jalons que vous validez l’un après l’autre : un périmètre signé, un prototype éprouvé sur vos données, une version déployée dans vos outils, puis des revues de suivi après la mise en service. Pour une direction qui engage un premier budget en intelligence artificielle, cette continuité entre cadrage, intégration et maintenance, prévue dès le départ, sécurise l’investissement.
Côté entreprise, la première semaine fixe le rythme du projet. Votre part tient en quatre livraisons, à préparer avant le lancement : un accès aux données du cas d’usage, ou un extrait représentatif accompagné de la personne qui sait le lire ; des comptes de test nominatifs aux droits limités ; un environnement de travail séparé de la production, validé par la DSI ; enfin deux interlocuteurs nommés, l’un côté métier, l’autre côté technique.
Chaque accès qui tarde décale d’autant le prototype, quel que soit le rythme du développement.
Données et environnements : le chemin critique
Le prototype ne démarre pas tant que les données manquent. Procédez en deux temps : un extrait représentatif d’abord, choisi avec le métier pour couvrir les cas courants comme les cas rares, puis l’accès complet une fois le périmètre confirmé.
Des données utiles, et seulement celles-là
Minimisez dès le départ. Un assistant destiné aux techniciens de maintenance exploite les notices et l’historique des pannes, jamais le fichier du personnel. Avec la génération augmentée par récupération, la base documentaire devient un livrable de l’entreprise : versions à jour, documents obsolètes retirés, droits de lecture définis.
Dans sa fiche pratique de juillet 2025 sur la sécurité du développement des systèmes d’IA, la CNIL recommande de contrôler les accès aux données par niveaux d’habilitation, de journaliser les consultations et de gérer les versions des jeux de données. Elle conseille aussi des données fictives ou de synthèse pour les tests de sécurité et l’intégration.
Trois environnements, cloisonnés
L’Agence nationale de la sécurité des systèmes d’information (ANSSI), dans ses recommandations de sécurité pour un système d’IA générative du 29 avril 2024, distingue trois phases, susceptibles de mobiliser des environnements et des populations différents : entraînement, déploiement, production. Elle recommande de les cloisonner, et d’administrer l’environnement de développement au même niveau de sécurité que la production.
Votre DSI tranche donc trois points avant le lancement : où travaille le prestataire, qui détient les comptes d’administration, comment une version passe d’un environnement à l’autre. Le même guide déconseille fortement de réentraîner un modèle directement en production, et proscrit l’envoi de données sensibles vers des outils grand public sur Internet.
Prototype, version pilote, version de production : ce que vous validez
Chaque jalon de livraison répond à une question différente. Un prototype jugé comme un produit fini déçoit ; une version pilote jugée comme une démonstration rassure à tort.
Le prototype vérifie une hypothèse
Le prototype, ou preuve de concept (proof of concept), répond à une seule question : le résultat attendu est-il atteignable avec vos données ? Il tourne hors de vos outils, sur l’extrait fourni. Le responsable métier juge les réponses sur des cas qu’il connaît, puis la direction poursuit, resserre le périmètre ou arrête.
La version pilote éprouve l’usage réel
Ce jalon place la version pilote dans le quotidien d’un petit groupe d’utilisateurs, branchée sur un vrai logiciel métier. Question : s’en servent-ils, et que font-ils quand la réponse est fausse ? L’ANSSI recommande de prévoir au minimum une procédure de contournement du système d’IA ; le pilote sert à l’éprouver, pendant que la DSI contrôle journalisation, droits et flux.
La version de production engage l’entreprise
La version de production suit la recette et un audit de sécurité, que l’ANSSI recommande de mener avant le déploiement, par des équipes formées aux spécificités de l’IA. La direction décide de la mise en service sur trois pièces : procès-verbal de recette, rapport d’audit, contrat de maintenance.
À chaque jalon, un procès-verbal court consigne la décision : accepté, accepté avec réserves, refusé. Il évite de rouvrir en fin de projet un débat tranché au prototype.
La recette fonctionnelle : jeux de test, cas limites, seuil d’acceptation
La recette est la vérification, par l’entreprise et avant acceptation, que le système fait ce que le cahier des charges prévoyait. Or une même demande produit parfois deux réponses différentes, et une erreur rare reste une erreur. Pour un tel système, la recette fonctionnelle se juge sur un ensemble de cas, jamais sur une démonstration.
Un jeu de test écrit avant le développement
Préparez le jeu de test pendant le cadrage, avec le métier : des cas réels et, pour chacun, la réponse qu’un collaborateur expérimenté donnerait. Gardez-en une partie à l’écart, invisible pour le prestataire pendant la mise au point. Un système réglé sur des exemples connus brille toujours sur ces mêmes exemples.
Les cas limites à inclure
Ajoutez ensuite des cas limites, choisis pour mettre le système en difficulté :
- des demandes hors périmètre, auxquelles le système doit répondre qu’il ne sait pas ;
- des documents incomplets, mal numérisés ou contradictoires ;
- des formulations ambiguës ou chargées d’abréviations maison ;
- un courriel piégé qui glisse des instructions destinées au modèle ;
- des pics de volume, pour mesurer les temps de réponse.
Un seuil d’acceptation défini par gravité
Plutôt qu’un pourcentage global, fixez le seuil d’acceptation par catégorie d’erreur. Une erreur bloquante, comme une donnée confidentielle montrée à la mauvaise personne ou une action déclenchée à tort, n’est tolérée sur aucun cas. Une erreur majeure reste acceptable si elle demeure rare et rattrapée par le contrôle humain prévu. Les erreurs mineures se discutent au regard du temps gagné.
La recette se rejoue : l’ANSSI précise que les tests fonctionnels d’un système d’IA peuvent tourner en continu, pas seulement lors des déploiements. Conservez le jeu de test pour chaque mise à jour du modèle.
Reprise par vos équipes et maintenance du système
Le dernier jalon est un transfert. Vos équipes reçoivent de quoi exploiter le système sans appeler le prestataire à chaque incident :
- la documentation de conception et de fonctionnement, que la CNIL recommande de réunir dans un recueil incluant les mesures de sécurité ;
- les accès d’administration, basculés sur des comptes de l’entreprise ;
- la procédure de mise à jour et de retour arrière ;
- le jeu de test et le procès-verbal de recette ;
- une formation des utilisateurs et des administrateurs.
La formation relève désormais d’une obligation : selon le calendrier publié par la Commission européenne, les règles du règlement (UE) 2024/1689 sur la maîtrise de l’IA s’appliquent depuis le 2 février 2025, et l’entreprise qui déploie un système d’IA veille à la compréhension suffisante de son personnel. Le guide pour se former à l’intelligence artificielle donne des repères aux référents internes.
La maintenance d’un système d’IA dépasse la correction d’anomalies : les données changent, les usages aussi, et un modèle tiers évolue parfois sans que votre code bouge. Le contrat précise qui surveille les indicateurs, à quel rythme se tiennent les revues et qui rejoue la recette. L’article consacré au MLOps, l’industrialisation d’un modèle jusqu’à la production, fournit le vocabulaire de cette discussion avec la DSI.
Ajoutez enfin un plan de réversibilité : ce que le prestataire restitue en fin de contrat, sous quel format et dans quel délai convenu. Il coûte peu à rédiger au cadrage, beaucoup à négocier lors d’une rupture.
Prochaine étape : réunissez la direction, le responsable métier et la DSI, et attribuez un nom à chacune des quatre livraisons de la première semaine. Tant qu’une case reste vide, le projet n’est pas prêt à signer.