orpilo

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
Envisagé choix privilégié à ce stade · À confirmer dépend du pilote ou du contrat · Hors périmètre explicitement exclu
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é :

{{it}}

Ce qu'Orpilo ne remplace pas Hors périmètre

{{it}}

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.

Composant
Fournisseur envisagé
Localisation visée
Statut
{{r.composant}}
{{r.fournisseur}}
{{r.localisation}}
{{r.statutLabel}}
{{r.composant}} {{r.statutLabel}}
Fournisseur{{r.fournisseur}} Localisation{{r.localisation}}

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.

Ce point devra être discuté explicitement avec toute entreprise pour qui l'hébergement du frontend ou des assets sur infrastructure américaine constitue une contrainte.

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 :

{{it}}

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 :

{{f.nom}} — {{f.role}}
La liste contractuelle finale, les localisations effectivement retenues et les mécanismes éventuels de transfert devront être documentés avant toute utilisation de données réelles.

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 :

{{it}}

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.