Déploiement On-Premise pris en charge dans Pilardin : périmètre et prérequis pour l'IA sur site

Ce qui change : une prise en charge du déploiement sur site, du socle au run

La prise en charge du déploiement sur site (On-Premise) est désormais assurée dans Pilardin. Concrètement, l'installation de la plateforme — conversation avec les documents, index RAG, connecteurs vers les systèmes métier et modules Matrix — ne relève plus d'un projet monté de façon artisanale par l'équipe IT du client, mais d'un mode de déploiement encadré et documenté. Le changement est opérationnel plus que marketing : dans la plupart des organisations, ce n'est pas le modèle d'IA qui bloque un projet, c'est son exploitation dans la durée.

Le problème est connu. Beaucoup d'initiatives d'IA d'entreprise ont échoué non pas sur la qualité des réponses, mais sur trois questions très matérielles : où sont stockés les documents et les index, qui met à jour les composants, et qui intervient quand un connecteur tombe en panne. Prendre en charge le déploiement sur site revient à assumer une partie de ces réponses de manière explicite, avec un périmètre défini, plutôt que de laisser chaque client réinventer sa propre procédure au fil de l'eau.

Cette annonce ne signifie pas que l'installation devient un simple clic. Elle signifie que le chemin est balisé : préparation de l'environnement, installation, connexion aux sources documentaires, indexation, puis cycle de mise à jour. Pour une direction informatique, la différence se mesure surtout au moment où le premier incident survient et où il faut savoir qui fait quoi.

Pourquoi l'On-Premise reste structurant pour l'IA d'entreprise

Le déploiement sur site répond d'abord à une contrainte de localisation des données. Dans la banque, l'assurance, la santé, l'industrie ou les administrations, le corpus qui alimente un assistant — contrats, dossiers, plans de maintenance, tickets, procédures internes — ne peut pas toujours transiter vers un service cloud externe. La résidence des données, les attentes des régulateurs et les politiques internes de classification pèsent souvent davantage que la performance brute d'un modèle.

Il répond aussi à des contraintes réseau. Un site industriel, un entrepôt ou une filiale peut disposer d'une connexion limitée ou intermittente, tout en ayant besoin de réponses immédiates sur des documents internes. Exécuter l'IA sur site réduit la dépendance au lien WAN et la latence perçue au poste de travail, ce qui change concrètement l'usage : un technicien consulte une procédure au pied de la ligne, pas depuis son bureau.

Reste le revers de la médaille, qu'il faut énoncer clairement : l'On-Premise déplace la charge d'exploitation vers le client. Dimensionnement du matériel, stockage vectoriel, sauvegardes, supervision, gestion des montées de version, sécurité du socle : ces tâches ne disparaissent pas parce qu'elles sont internalisées. C'est précisément là qu'une prise en charge structurée fait la différence entre un pilote qui s'arrête au bout de trois mois et un service qui tient sur une année complète.

Le périmètre : ce qui est pris en charge, ce qui reste côté client

Dire que la prise en charge du déploiement est assurée ne veut pas dire que tout est automatique ni que le client n'a aucun rôle. Le partage des responsabilités doit être lu avant l'engagement, car il détermine le coût réel du projet : budget matériel, jours-homme internes et fenêtres de maintenance. La lecture la plus utile consiste à séparer ce qui vient de la plateforme et ce qui vient de votre infrastructure.

Sur le plan économique, la question centrale est le coût total, pas le seul coût de licence. Un serveur surdimensionné pour un usage réel de quelques dizaines de requêtes simultanées coûte plus cher qu'un service hébergé ; à l'inverse, un usage intensif et continu sur des volumes documentaires importants peut rendre le sur-site plus prévisible budgétairement. La comparaison pertinente n'est donc pas « cloud contre sur site » dans l'abstrait, mais « quel volume, quels documents, quelles contraintes de conformité, sur quel horizon ».

• Socle applicatif et installation — pris en charge dans l'environnement du client / choix de l'hyperviseur, du réseau et des certificats — à la charge de l'IT cliente.
• Connexion aux sources documentaires et indexation RAG — accompagnée / ouverture des flux, comptes de service et droits d'accès — préparés côté client.
• Modules Matrix et connecteurs vers les systèmes métier — intégrés au même espace de travail / disponibilité effective des API internes — à valider par les équipes systèmes.
• Mises à jour et correctifs — encadrés par un canal défini / planification des fenêtres et sauvegardes préalables — responsabilité partagée.
• Supervision et support — journaux d'exécution et traces d'audit disponibles / astreinte de premier niveau sur l'infrastructure — côté client.

Ce que cela implique pour les équipes IT, sécurité et métier

Pour l'équipe informatique, le principal chantier n'est pas l'installation mais l'intégration. Un assistant interne crédible doit refléter les droits existants : un utilisateur ne doit pas obtenir, via le chat, un document qu'il n'aurait pas pu ouvrir dans le système source. Cela suppose de connecter l'authentification — annuaire, SSO — de propager les permissions et de journaliser les consultations, faute de quoi la plateforme devient un contournement silencieux des règles d'accès.

Pour les équipes sécurité et conformité, le déploiement sur site facilite certaines exigences et en crée d'autres. La résidence des données devient plus simple à démontrer ; en revanche, la traçabilité, la gestion des secrets, la revue des journaux et la politique de rétention passent sous votre contrôle, donc sous votre responsabilité. Il est utile d'établir dès le départ la liste des flux sortants éventuels et de la faire valider avant la mise en production.

Pour les métiers, la valeur ne vient pas du mode de déploiement mais de l'usage réel. Un index RAG qui n'est pas rafraîchi produit des réponses périmées ; un espace de travail sans règle de nommage des sources devient illisible au bout de quelques semaines. Prévoir un propriétaire du corpus, une cadence de réindexation et un canal de remontée des réponses douteuses compte davantage que le choix du processeur.

Pour cadrer ce périmètre avant de trancher, les équipes peuvent examiner les modules spécialisés disponibles (/matrix) ou les modalités d'accompagnement et niveaux d'offre (/pricing), afin d'aligner l'architecture cible sur les contraintes internes plutôt que sur un catalogue fonctionnel.

Ce qu'il faut surveiller

La prise en charge du déploiement ne clôt pas le sujet : elle déplace le débat vers l'exploitation. Une plateforme d'IA sur site se juge sur ce qu'elle produit au quotidien, pas sur la réussite de sa journée d'installation. Quelques indicateurs simples suffisent à détecter une dérive avant qu'elle ne devienne un abandon.

Un déploiement sur site réussi s'évalue donc moins au jour de la mise en service qu'au trimestre suivant, quand il faut mettre à jour, réindexer, ajuster les permissions et absorber de nouveaux cas d'usage. C'est ce cycle-là que la prise en charge doit rendre prévisible, et c'est là que se joue la différence entre une démonstration interne et un outil de travail.

• Fraîcheur du corpus : écart entre la dernière modification d'un document et sa prise en compte dans l'index.
• Qualité des réponses ancrées : part des réponses citant une source interne vérifiable plutôt qu'une reformulation vague.
• Coût de fonctionnement : charge matérielle réellement consommée, temps de réponse, incidents liés aux connecteurs.
• Adoption : utilisateurs actifs par service et questions récurrentes sans réponse, qui révèlent les lacunes documentaires.

FAQ

La prise en charge du déploiement sur site signifie-t-elle que toutes les données restent dans notre réseau ?

Dans un déploiement On-Premise, les documents, les index vectoriels et les traitements applicatifs s'exécutent dans votre environnement. Certains flux périphériques — vérification de licence, dépôt de correctifs, éventuelle télémétrie de diagnostic — peuvent néanmoins nécessiter un canal sortant. La bonne pratique est d'en demander la liste exhaustive, avec les destinations et la possibilité de les désactiver ou de les relayer via un proxy interne, puis de faire valider cette liste par vos équipes sécurité avant la mise en production.

Faut-il nécessairement des GPU pour faire tourner Pilardin sur site ?

Cela dépend du volume de documents, de la latence attendue et des modèles utilisés. Un déploiement orienté recherche documentaire sur un corpus limité peut fonctionner avec des ressources plus modestes, tandis qu'un usage fortement concurrent avec génération de réponses longues pousse vers un accélérateur matériel. Le dimensionnement doit être établi à partir de mesures d'usage réelles et de tests de charge, pas d'hypothèses ; c'est un point à traiter en amont avec l'équipe infrastructure plutôt qu'après l'installation.

Comment se passent les mises à jour quand la plateforme est installée chez nous ?

Le cycle de mise à jour est le point de fragilité classique d'une plateforme sur site. Le principe raisonnable consiste à définir à l'avance une cadence — par exemple trimestrielle —, une procédure de sauvegarde et de retour arrière, ainsi qu'un environnement de préproduction pour tester les correctifs avant diffusion. Sans ce cadre, l'installation se fige sur une version obsolète, et les nouveaux connecteurs ou modules ne peuvent plus être adoptés sans risquer de casser l'existant.