Beaucoup d'entreprises lancent leur premier projet d'IA comme une experience isolee. Une equipe rassemble des documents, monte sa propre base de donnees et la connecte a un outil d'IA. Les premiers resultats semblent prometteurs et vous avez le sentiment d'avoir quelque chose de solide entre les mains. Quelques mois plus tard, vous constatez que les memes informations se trouvent aussi dans l'ERP, dans le CRM, dans des dossiers partages et dans une poignee de fichiers Excel. Personne ne sait plus quelle version est la bonne. L'IA qui devait rendre l'information plus accessible a entre-temps construit un nouveau silo de donnees.
Ce qu'est reellement un silo de donnees
Un silo de donnees est un ensemble de donnees que vous stockez a l'interieur d'une application, d'un service ou d'une equipe, sans veritable lien avec le reste de l'organisation. Ces donnees ne sont pas disponibles pour d'autres processus, ne sont pas rattachees a une source claire, utilisent souvent leurs propres definitions et sont difficiles a maintenir a jour. En general, seule une petite equipe y a acces et le silo echappe a votre politique generale de gestion des donnees. L'IA amplifie ce risque, parce que vous montez rapidement des projets pilotes avec des copies et des plateformes distinctes qui vivent a cote de vos systemes existants.
Pourquoi les silos d'IA apparaissent si facilement
La premiere raison est la vitesse. Les experiences doivent montrer quelque chose de tangible, alors l'equipe exporte les donnees necessaires depuis les systemes existants vers un espace de travail separe. Ce qui commence comme une copie temporaire pour un pilote se transforme insensiblement en source permanente sur laquelle repose l'ensemble du projet.
Une deuxieme raison vient des fournisseurs eux-memes. Beaucoup de solutions d'IA vous demandent de televerser documents et donnees sur leur plateforme. Vous y construisez ensuite un environnement separe, avec sa propre gestion des acces, son propre versioning et sa propre vision de ce qu'est la verite.
La troisieme raison est l'effort necessaire pour acceder aux donnees sources. Une connexion directe a l'ERP ou au CRM parait complexe et chronophage, donc vous optez pour une copie parce qu'elle semble plus simple. Quelques mois plus tard, la copie et la source divergent et personne ne sait laquelle compte.
La quatrieme raison est la responsabilite floue. Tant que personne n'est formellement responsable des donnees dans l'outil d'IA, les corrections n'ont lieu qu'a cet endroit et la source reste erronee. C'est ainsi qu'un systeme parallele grandit lentement sans jamais avoir ete confronte aux donnees d'origine.
Commencez par la question de savoir ou se trouve la verite
Avant de commencer a construire, decidez pour chaque type d'information quel systeme fait office de source. Les donnees clients appartiennent au CRM, les donnees produits a l'ERP ou au PIM, les transactions a la comptabilite, les contrats a la GED, les donnees du personnel aux RH. Une fois ces choix arretes, un outil d'IA peut utiliser ces informations sans en faire discretement une verite alternative.
Ne copiez qu'avec un objectif clair
Parfois vous n'avez pas le choix et vous devez copier des donnees de facon temporaire ou pour des raisons techniques. Consignez alors explicitement ce que vous copiez, pourquoi, a quelle frequence vous rafraichissez cette copie, combien de temps vous la conservez, qui y a acces, comment les corrections remontent et ce qui se passe si vous arretez le projet. Une copie sans accords devient presque toujours un risque.
Faites remonter les corrections vers la source
Imaginez qu'un collaborateur remarque via l'IA qu'une description produit est incorrecte. Si vous n'appliquez la correction que dans l'environnement d'IA, tous les autres systemes restent faux. Concevez donc un processus dans lequel les corrections ont lieu dans le systeme source, y sont validees et redescendent ensuite vers l'outil d'IA. Ainsi votre IA reste un consommateur des donnees et non une source independante a cote.
Utilisez les definitions existantes
Un nouveau projet d'IA ne doit pas decider seul de ce que signifient chiffre d'affaires, client actif, date de livraison ou groupe de produits. Si vous constatez que ces definitions ne sont pas claires, le projet d'IA met au jour un probleme de gouvernance que vous devez traiter de facon centralisee. Sinon votre IA produira des analyses propres sur la base de la mauvaise definition et vous perdrez confiance dans les resultats.
Pensez tot a l'integration
Un projet pilote peut encore tourner avec des televersements manuels pour tester une hypothese. Pour un usage structurel, vous avez besoin d'une integration geree. Determinez quels systemes fournissent les donnees, a quelle frequence elles se rafraichissent, comment vous remontez les erreurs, ce que l'IA a le droit de reecrire, quels controles vous placez en amont et comment vous surveillez le flux. Ainsi l'outil d'IA reste une piece controlee de votre paysage.
Evitez un modele d'acces separe
Une plateforme d'IA contient souvent des informations sensibles. Utilisez votre gestion des identites et des acces existante et ne montez pas de structure de droits separee. Les collaborateurs ne doivent voir via l'IA que ce qu'ils seraient egalement autorises a voir sans elle. Quiconque n'a pas acces au dossier des contrats ne doit pas non plus pouvoir en consulter le contenu via un chatbot.
Fixez la propriete des donnees
Pour chaque source de donnees importante, il vous faut quelqu'un de responsable de la qualite, des definitions, des droits, des corrections, des durees de conservation et de la disponibilite. La DSI exploite l'infrastructure mais n'est pas automatiquement proprietaire du sens ou de la qualite des donnees commerciales ou financieres. Cette propriete se place du cote metier, avant que vous ne fassiez la premiere copie.
Prevoyez un plan de sortie
Un silo de donnees est encore plus problematique lorsque vos donnees ne vivent que dans la plateforme du fournisseur. Fixez a l'avance dans quel format vous pouvez tout exporter, si les configurations et metadonnees suivent, comment vous faites supprimer les donnees de l'entreprise, combien de temps les sauvegardes restent en place, quelle documentation est disponible et comment un autre fournisseur pourrait reprendre la solution.
Verifiez l'architecture avant la mise a l'echelle
Pour un pilote, tout n'a pas besoin d'etre parfait, mais pour la mise a l'echelle si. Vous devriez au minimum cartographier ou vivent les donnees d'origine, quelles donnees vous avez copiees, comment se deroulent les mises a jour, qui a acces, ou sont stockes les resultats, comment fonctionnent les corrections et ce qui se passe si vous arretez. Sans cette vue d'ensemble, vous mettez a l'echelle un silo cache en meme temps que tout le reste.
Pour conclure
Un projet d'IA cree un nouveau silo au moment ou la vitesse devient plus importante que la coherence. Traitez votre solution d'IA comme une partie de votre paysage d'information existant, avec des sources fiables, des corrections qui remontent et des regles d'acces qui se branchent sur votre politique existante. Alors l'IA renforce votre gestion de l'information au lieu de batir un systeme parallele a cote.
Voulez-vous eviter que votre projet d'IA devienne un systeme parallele?
L'Analyse SEMANU cartographie les systemes sources, place l'outil d'IA dans votre architecture existante et definit la propriete, l'integration et les criteres de sortie avant que vous ne construisiez. Investissement unique a partir de 4400 euros.
Questions frequentes
Qu'est-ce qu'un silo de donnees et comment le reconnaitre dans un projet d'IA?
Un silo de donnees apparait lorsqu'un outil d'IA se constitue ses propres copies, ses propres definitions ou ses propres droits d'acces a cote des systemes existants. Vous le reconnaissez a des corrections qui n'ont lieu que dans l'environnement d'IA, a des rapports qui affichent d'autres chiffres que l'ERP et a un fournisseur qui demande sans cesse de nouveaux televersements.
Pouvez-vous copier des donnees vers une plateforme d'IA?
Parfois une copie technique est incontournable, mais consignez alors explicitement ce que vous copiez, a quelle frequence, combien de temps vous la conservez, qui y a acces et ce qui se passe a l'arret du projet. Sans ces accords, la copie devient presque toujours un risque.
Qui est proprietaire des donnees dans un projet d'IA?
Chaque source de donnees importante a un proprietaire pour la qualite, les definitions, les droits et les durees de conservation. La DSI exploite l'infrastructure mais n'est pas automatiquement proprietaire du sens commercial ou financier. Vous devez attribuer cette propriete au prealable.
Que doit contenir un plan de sortie pour un fournisseur d'IA?
Dans quel format vous pouvez exporter les donnees, si les configurations et metadonnees suivent, combien de temps les sauvegardes subsistent, comment vous faites supprimer les donnees d'entreprise et quelle documentation est disponible pour qu'un autre fournisseur puisse reprendre la solution.