Centre documentaire
Questions fréquentes sur la sécurité, la confidentialité et le pilote
Orpilo est testé avec des maquettes HTML et un parcours de démonstration. Cette page explique le cadre envisagé pour un futur pilote, les choix d'infrastructure privilégiés, et les limites assumées à ce stade.
- Version
- V1
- Mise à jour
- 15/08/2026
- Périmètre
- Phase pré-pilote — avant build complet
Sommaire
Le sujet traité
Orpilo vise un problème très précis : la réception, la vérification, la diffusion interne et le suivi des révisions client externes.
L'objectif n'est pas de remplacer votre GPAO, votre ERP, votre PLM ou votre GED. L'objectif est de mieux gérer le dernier kilomètre entre la réception d'un changement client et sa prise en compte visible par les personnes concernées.
Ce que le pilote couvrirait Envisagé
Le périmètre envisagé pour un premier pilote est volontairement limité :
Ce qu'Orpilo ne remplace pas Hors périmètre
Le futur produit serait un outil complémentaire, centré sur la circulation et la traçabilité des révisions clients externes.
Aucune diffusion sans validation humaine
L'approche retenue est simple : l'IA peut aider à préparer un brouillon, mais elle ne doit pas diffuser seule une information interne.
Avant toute diffusion, un utilisateur de l'entreprise relit, corrige si besoin, puis valide explicitement la fiche.
Orpilo ne se substitue pas au contrôle qualité ni à la responsabilité des équipes.
Infrastructure envisagée
Le futur pilote privilégie une architecture européenne quand cela est possible et réaliste pour le cas d'usage.
« Fournisseur européen » ne signifie pas automatiquement « aucune donnée hors UE ».
Avant un pilote, la région réellement configurée pour la base, le VPS d'automatisation, l'email et l'API IA sera fournie, ainsi que les transferts éventuels.
Ce choix permet d'aller vite pour tester le besoin. Si les exigences sécurité, hébergement ou conformité d'un pilote l'imposent, une option de code export et de self-hosting restera envisageable.
Le premier choix envisagé pour l'extraction assistée est Anthropic. Si un pilote exige une alternative différente pour des raisons de souveraineté ou de politique fournisseur, une bascule vers une option comme Mistral pourra être étudiée.
Confidentialité et documents techniques
Les documents techniques ne contiennent pas seulement des données personnelles. Ils peuvent aussi contenir des références, tolérances, prix, plans ou informations relevant du secret d'affaires ou d'un NDA.
Le futur pilote devra donc encadrer :
En phase de démonstration, les parcours doivent utiliser des données fictives ou anonymisées.
Fournisseurs envisagés
La liste précise devra être fournie avant tout pilote réel. À ce stade, les briques envisagées sont :
Dans le setup actuel envisagé, toutes les briques ne sont pas localisées au même endroit. La base de données et les automatisations peuvent être privilégiées en Europe, tandis que le frontend WeWeb publié reste, selon la documentation consultée, hébergé sur AWS aux États-Unis tant qu'un self-hosting n'est pas retenu.
Cadre RGPD envisagé À confirmer
Dans le cadre d'un futur pilote, l'entreprise cliente resterait en principe responsable du traitement pour ses propres données et Orpilo agirait comme sous-traitant pour les traitements réalisés sur instruction.
Les rôles exacts, la durée de conservation, les sous-traitants et les obligations respectives devront être précisés dans les documents contractuels et le DPA.
Un DPA devra être signé avant tout traitement de données réelles. Il décrira l'objet et la durée, les instructions, la confidentialité, la sécurité, les sous-traitants ultérieurs, l'assistance aux droits, les incidents, la suppression ou la restitution, et l'audit.
Export et suppression
Le pilote vise un fonctionnement simple : une entreprise doit pouvoir récupérer ses données utiles, demander une suppression, et comprendre le délai de purge, y compris pour les sauvegardes résiduelles si elles existent.
Les modalités exactes devront être décrites avant toute utilisation réelle.
En cas d'incident
Le futur pilote devra définir un contact support, une procédure d'incident, et une façon claire d'informer l'entreprise concernée si un problème affecte ses données ou la disponibilité du service.
À ce stade, aucun engagement de SLA ou de délai contractuel ne doit être promis sans capacité opérationnelle correspondante.
Ce qui serait fourni avant un pilote
Avant tout pilote portant sur des données réelles, un ensemble de pièces serait remis et discuté avec l'entreprise concernée :
Aucune certification n'est détenue à ce stade, et aucune n'est revendiquée sur cette page. Ces pièces décrivent la configuration réellement retenue, pas un label.
Questions fréquentes
Les réponses complètes sont regroupées sur la page Questions fréquentes.
Voir toutes les questions fréquentes →Vous avez une question sur le pilote ?
Les points marqués « à confirmer » se décident au cas par cas, avec l'entreprise concernée.