# Avanoo documentation (/docs) Welcome to the Avanoo documentation. Use these guides to prepare your organization, deploy the browser extension, understand our privacy model, and operate Avanoo in production. ## Start with the right path [#start-with-the-right-path] * [Overview](/docs/getting-started/what-is-avanoo) explains the platform and the first steps for an administrator. * [What Avanoo collects](/docs/security-and-privacy/data-collection-overview) is the data inventory to share with a DPO or vendor review. * [Hosting, security, and compliance](/docs/security-and-privacy/hosting-security-and-compliance) covers residency, subprocessors, encryption, and certifications. If you are choosing how Avanoo should identify users, begin with the public [identity mode comparison](/docs/deployment/identity/compare). The extension is deployed through Group Policy, Intune, Google Workspace, or an equivalent. # Accessing the documentation (/docs/getting-started/accessing-documentation) Customer documentation is connected to your Avanoo organization. The content you see can depend on your organization’s lifecycle stage and enabled capabilities. ## Customer administrators [#customer-administrators] Sign in to the Avanoo platform with your existing organization account, then open the documentation link from the platform. The documentation session uses the same identity as the platform; you should not need a second documentation password. ## Implementation partners and MSPs [#implementation-partners-and-msps] If an implementation partner needs deployment or integration guidance, invite them to the relevant Avanoo organization through the platform. This gives them the correct scope without sending organization-specific deployment material as an offline package. Once you are signed in to the documentation with an organization, use **Share link** in the account bar. Send that URL to a technician who does not yet have platform access. Treat the link like a credential: use it only for the intended engagement and do not forward it. ## If a guide is missing [#if-a-guide-is-missing] A missing page can mean that: * your organization is not entitled to the capability; * the guide is only available during onboarding; or * your administrator has not provisioned the required access yet. If the guide is still unavailable, contact your Avanoo administrator through the platform. # What is Avanoo? (/docs/getting-started/what-is-avanoo) Avanoo helps organizations understand and improve the way they use SaaS applications. It brings together usage, identity, security, and governance signals so that IT teams can make informed decisions about their technology environment. ## What you can do with Avanoo [#what-you-can-do-with-avanoo] * Discover which SaaS applications and browser extensions are in use. * Identify unused licenses and opportunities to reduce cost. * Understand security and privacy risks across the SaaS environment. * Give administrators useful reports and operational context. * Help employees move toward approved applications through in-browser guidance. The browser extension collects metadata required for these capabilities. The exact signals available to your organization depend on the modules and monitoring settings enabled for your environment. For a vendor, DPO, or security review, start with [What Avanoo collects](/docs/security-and-privacy/data-collection-overview) and [Hosting, security, and compliance](/docs/security-and-privacy/hosting-security-and-compliance). ## A note about deployment [#a-note-about-deployment] Avanoo is normally deployed through Group Policy, Intune, Google Workspace, or an equivalent browser policy. Before choosing a deployment procedure, review the public [identity mode comparison](/docs/deployment/identity/compare). Once your organization has platform access, your implementation team will receive the stage-specific deployment instructions for the selected identity mode. # What Avanoo collects (/docs/security-and-privacy/data-collection-overview) Avanoo maps SaaS and AI usage from the browser. It is designed to give IT, security, and procurement useful visibility **without collecting the content of the activity it observes**. This page is the data inventory to share with a DPO, CISO, works council, or vendor review. Hosting, encryption, subprocessors, and certifications are on [Hosting, security, and compliance](/docs/security-and-privacy/hosting-security-and-compliance). ## Design in one sentence [#design-in-one-sentence] Avanoo collects **metadata** (which professional application was used, when, and under which identity rules you chose), not emails, files, prompts, passwords, or browsing outside the applications you allow. There is no operating-system agent and no network proxy. The only component installed on a workstation is a browser extension, deployed by your organization on professional devices. ## Two controls sit in front of every event [#two-controls-sit-in-front-of-every-event] Nothing is produced until both of these are true. 1. **An allowlist of domains.** The extension only treats domains your organization has registered. Any other navigation is ignored before processing: no event is created, and there is no way to reconstruct that visit later. The list is visible and exportable from the platform. Avanoo’s starting catalogue is professional applications only — not personal webmail, consumer social networks, banking, health, trade-union, or job-search sites. You remain in control of the list, including custom URLs for on-premise applications opened in the browser. 2. **Per-capability switches, off by default.** Each monitoring capability has its own organization-level switch. Turning one on or off applies to the whole fleet without an extension update. Changes are logged. The identity mode (Identified, Pseudonymous, or Anonymous) decides **who an event is attached to**. It does not expand what the extension is allowed to observe. ## Data sources [#data-sources] | Source | What it contributes | Required? | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ | | Browser extension (Chrome, Edge, Brave, Firefox) | Usage, authentication, AI, MCP, extension-inventory, and data-activity metadata from professional browsers | Yes, for discovery | | Directory ingestion (Microsoft Entra, Google Workspace, Keycloak) | Users, groups or org units, and optionally sign-in or OAuth-consent context | Optional | | SCIM or CSV | User and group lists when a directory connector is not used | Optional | | Application catalogue | Compliance metadata about the applications themselves (certifications, hosting region, retention posture). This is product reference data, not employee data | Included | Directory, SCIM, and CSV integrations enrich identity and grouping. They are not a substitute for the extension, and they are not Avanoo subprocessors — they are systems you already operate. ## What is collected [#what-is-collected] The table below is the inventory. A row only applies when that capability is enabled for your organization. | Capability | Form stored | Typical purpose | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Allowlisted application domain | Registrable domain only — not the path inside the site | SaaS and Shadow IT mapping | | Visit time | Timestamp, then aggregated to monthly usage | Frequency of use, license reconciliation | | Authenticated vs visited | Boolean | Distinguish a real session from a drive-by | | Browser-install signature | Stable technical ID for that browser install, not a person | Count distinct browsers; stitch events from the same install | | Professional identity or alias | Real work email, organization-controlled alias, or none — see identity modes below | Attribute usage to a person or a cohort | | Sign-in metadata | Method type, success or failure, consecutive failures | Detect stuffing attacks, not employee performance | | MFA metadata | Type of second factor observed | Measure MFA coverage | | SSO / OAuth / SAML metadata | Identity provider, target application, permissions requested | Check SSO policy and third-party grants | | Passkeys / WebAuthn | Authenticator type only — the secret is never captured | Inventory phishing-resistant authentication | | Password reuse and strength | Irreversible, per-user fingerprint computed in the browser. Avanoo never receives the password or the comparison hash | Find reused credentials across apps | | Installed browser extensions | Name, version, publisher, permissions, state | Browser attack-surface inventory | | AI usage | Service name, timestamp, prompt **count** and **length**, enterprise vs personal account | Shadow AI mapping without prompt content | | MCP connections | Server name, tool name, authorization signals | See which AI clients were granted the ability to act | | File and transfer metadata | File name, size, MIME type, destination domain | Investigate uploads to unsanctioned storage or AI tools | | Clipboard and drag-and-drop | Text length and file count, not content | Data-movement signal | | Local DLP labels (optional) | Detector **labels and counts** only, computed in the browser | Flag sensitive-data categories without sending the text | | Campaign replies | Voluntary answers to questions your administrators send | Adoption and sentiment, Identified mode only | Catalogue records about applications (security score, certifications, country of processing) are not personal data. ## What never leaves the browser — and what is never collected [#what-never-leaves-the-browser--and-what-is-never-collected] | Never collected or transmitted | Detail | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email, chat, or document **content** | Page structure may be read in memory to recognise a login screen. Displayed text is not stored or sent | | AI prompt or response **content** | Only a count and a character length leave the browser | | File **contents** | Name, size, type, and domain only | | Clipboard **contents** | Length and type only | | Passwords | Transformed immediately in the browser. Avanoo never receives plaintext or a reversible hash | | Keystrokes, screenshots, or webcam/microphone | Not implemented | | Browser history | Neither read nor stored | | Navigation off the allowlist | No event is created | | Personal email addresses in full | When an address is classified as personal, the local part is stripped in the browser before anything is stored (`jane.doe@gmail.com` becomes `@gmail.com`) | | Real-time employee supervision | Events are batched asynchronously. There is no live monitoring screen. In-browser nudges are computed locally from already-deployed policy | | Individual performance scoring | Finalities are security, compliance, estate management, and awareness — not HR evaluation | Avanoo does not resell customer data, use it for advertising, or train foundation models on it. Data is processed only to provide the contracted service. ## Identity modes [#identity-modes] Identity is chosen at deployment and can be changed from the platform without redeploying the extension. | Mode | What Avanoo receives | What you can see | | ---------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | **Identified** | The user’s real professional identity | Named-user analytics, real groups, cross-device reconciliation, individual guidance | | **Pseudonymous** | A stable alias your organization generates. Avanoo never receives the mapping back to the person | Per-user and group analytics under the alias | | **Anonymous** | A device signature only | Coarse usage by application. Legacy mode — do not choose it for a new deployment without confirming the use case with Avanoo | No identity mode changes the “never collected” list above. Use the [identity mode comparison](/docs/deployment/identity/compare) with stakeholders, then the [privacy model](/docs/security-and-privacy/usage-modes-and-privacy) for the responsibilities each mode places on your organization. ## Application catalogue [#application-catalogue] The same catalogue is used by the browser extension, SSO matching, and optional directory signals: * more than 110,000 professional applications, updated weekly (especially new AI tools); * customizable per organization, including client-specific URLs for on-premise applications opened in the browser; * exportable from the platform so a DPO or works council can see exactly which domains are in scope. ## Retention [#retention] Confirm the values in your contract. The default model is: | Data | Retention | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Application visit timestamps | Aggregated to monthly usage within a few days. After that, “who opened which app at 14:32 on Tuesday” no longer exists | | Security and data-movement events (sign-ins, OAuth/SAML grants, MCP, files, clipboard) | Kept as individual events for a contractual period, because incident investigation needs the precise event. Usage and connection data: **12 months maximum** | | Monthly aggregates | Duration of the contract | | Platform access and configuration logs | At least 12 months | | Campaign replies | Duration of the contract, unless a shorter period is agreed | | Leaver | Deleted on the customer’s instruction | | End of contract | Returned or destroyed on written instruction; otherwise destroyed within one year of the DPA ending | ## Roles [#roles] The **customer is the controller**. Avanoo is the **processor** under a Data Processing Agreement (GDPR Article 28). Legal basis, employee information, works council consultation, and the record of processing activities sit with the customer. Avanoo assists with data-subject requests and DPIAs using the information it holds. ## Related pages [#related-pages] * [Hosting, security, and compliance](/docs/security-and-privacy/hosting-security-and-compliance) — residency, encryption, subprocessors, certifications. * [Usage modes and privacy](/docs/security-and-privacy/usage-modes-and-privacy) — Identified vs Pseudonymous responsibilities. * [Compare identity modes](/docs/deployment/identity/compare) — stakeholder-facing choice. # Hosting, security, and compliance (/docs/security-and-privacy/hosting-security-and-compliance) This page covers residency, security measures, subprocessors, and compliance posture. For the data inventory itself, start with [What Avanoo collects](/docs/security-and-privacy/data-collection-overview). ## Hosting and residency [#hosting-and-residency] Avanoo is a multi-tenant SaaS. The application, databases, and backups run on **Amazon Web Services** in the European Economic Area: * **Primary:** AWS Europe (Paris), `eu-west-3` * **Redundancy:** AWS Europe (Frankfurt), `eu-central-1` Customer data is stored and processed in these EU regions. Standard service delivery does not transfer usage data outside the EEA. Failover between Paris and Frankfurt is documented and manual. Avanoo does not operate its own datacenter. There is no OVH or Google Cloud hosting path for the production service. AI inference for the optional in-product assistant uses **AWS Bedrock in the EU only**. The diagram below is the production architecture in the primary Paris region. Frankfurt is used for redundancy and is not shown. ![Avanoo production architecture in AWS eu-west-3 (Paris). The web app at app.avanoo.ai authenticates administrators through Clerk into EC2. Browser extensions send application, email, and extension identifiers over HTTPS to API Gateway, a Lambda authorizer, SQS, and Lambda. Scheduled Lambdas call Microsoft Graph and other SaaS APIs. Data is written to S3 and to RDS inside a VPC, including a customer-dedicated RDS instance.](/images/security/infrastructure-eu-west-3.png) ## Encryption and keys [#encryption-and-keys] | Layer | Measure | | ---------- | --------------------------------------------------------------------------------------------- | | In transit | TLS 1.2 or higher. Certificates issued and renewed through AWS Certificate Manager | | At rest | AES-256 on RDS (PostgreSQL) and S3 (SSE-S3 or SSE-KMS) | | Keys | AWS KMS, no local key handling, access restricted and logged | | Backups | Encrypted RDS snapshots (7-day default) and versioned S3 objects, with periodic restore tests | ## Isolation and access [#isolation-and-access] * Customer environments are **logically isolated** in the database and in logs. There is no application-level mixing of tenant data. * Dashboard access uses named accounts through SSO, with three roles: Read, Analyst, and Admin. Multi-factor authentication is enforced by the customer’s identity provider. * Avanoo staff access follows least privilege, named IAM accounts with MFA, and AWS SSO. Direct database access is forbidden except for maintenance. * Access to data, failed access, and suspicious behaviour are logged (AWS CloudTrail and GuardDuty). Logs are kept at least 12 months. ## Subprocessors [#subprocessors] Distinguish three things that vendor questionnaires often mix up. **Processors of customer data in the service** | Subprocessor | Role | Location | | ------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Amazon Web Services | Hosts the application, databases, object storage, and backups | EEA (Paris, Frankfurt) | | Clerk | Authenticates **administrators** of the Avanoo dashboard (SAML, OIDC, SCIM) | See the DPA annex. Clerk does not identify employees in the browser extension | | AWS Bedrock | Optional in-product assistant | EU region only | The contractual list, retention, and notice period for changes are in the Data Processing Agreement annex. Avanoo notifies customers before adding or replacing a subprocessor. Transfers outside the EEA, if any, use GDPR-appropriate safeguards such as the European Commission’s standard contractual clauses. **Not Avanoo subprocessors** * **Your identity providers** (Microsoft Entra, Google Workspace, Okta, and others) remain your systems. Connecting them is optional and under your control. * **GitHub** is Avanoo’s source control. It does not host customer tenant data. * **Google Workspace** and **Vanta** are Avanoo internal collaboration and compliance tooling. They are not used to process your employees’ usage events. ## GDPR [#gdpr] | Topic | Position | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Roles | Customer = controller. Avanoo = processor (DPA, GDPR Article 28) | | DPO | External DPO (law firm Acmai). Contact **[privacy@avanoo.ai](mailto:privacy@avanoo.ai)** or **[dpo@avanoo.ai](mailto:dpo@avanoo.ai)** | | Security contact | **[security@avanoo.ai](mailto:security@avanoo.ai)** (CISO) | | Minimisation | Metadata only; allowlist; per-capability switches off by default; see [What Avanoo collects](/docs/security-and-privacy/data-collection-overview) | | Employee information, DPIA, works council | Customer responsibility. Avanoo provides the inventory and assistance | | Breach notification | Avanoo notifies the customer as soon as possible by email and cooperates under Articles 33 and 34 | | End of contract | One month to request return or destruction; otherwise destruction within one year of the DPA ending | Avanoo is a French company: Avanoo SAS, 54 rue du Faubourg Poissonnière, 75010 Paris, SIREN 925 197 519. ## Certifications [#certifications] Avanoo **does not** currently hold ISO 27001, ISO 27701, SOC 2, SecNumCloud, or HDS certification of its own service. What is in place: * A documented information-security policy (PSSI), available as a PDF on request. * Independent external penetration testing. * Internal security reviews. * An **ISO/IEC 27001** programme (tooling via Vanta), with certification targeted for **2027**. SOC 2 tracking is in the same programme; Avanoo is not SOC 2 certified today. * Hosting on AWS, which holds its own ISO 27001, SOC, and (in France) **HDS** attestations. Infrastructure questions about HDS or SecNumCloud therefore refer to the hosting provider, not to Avanoo’s application. ## Continuity [#continuity] Backups are automated and encrypted. Restore tests are periodic. A continuity and recovery plan covers failover between Paris and Frankfurt, with annual crisis exercises. ## Documents available on request [#documents-available-on-request] Share these with a prospect, DPO, or works council rather than paraphrasing them: * Data Processing Agreement (processor contract, including the subprocessor annex) * This documentation: [What Avanoo collects](/docs/security-and-privacy/data-collection-overview) and this page * Privacy policy: [avanoo.ai/legal/privacy-policy](https://avanoo.ai/legal/privacy-policy) * Information-security policy (PSSI) and security-assurance plan * External penetration-test report, under NDA * Works-council briefing template, when the deployment is in France For a feature-specific setting (which switches are on in a given tenant), the customer administrator exports the configuration from the platform, or asks their Avanoo representative. # Usage modes and privacy (/docs/security-and-privacy/usage-modes-and-privacy) Avanoo supports different levels of identity visibility so that each organization can choose the right balance between analytics and privacy. ## The privacy spectrum [#the-privacy-spectrum] * **Anonymous** provides the least identity information and the least per-user functionality. It is a legacy mode for highly restricted or transitional deployments. * **Pseudonymous** provides accurate per-user and group analytics through aliases while keeping the real identity mapping inside your organization. * **Identified** provides the richest named-user view and uses real identities from your directory or identity provider. No identity mode changes what the extension is allowed to collect. Monitoring capabilities are controlled separately by organization settings. ## Privacy responsibilities [#privacy-responsibilities] ### For Identified deployments [#for-identified-deployments] Before deploying Identified mode, confirm that your organization is allowed to send real user identities to Avanoo. Keep directory membership and administrator access limited to the people who need it. ### For Pseudonymous deployments [#for-pseudonymous-deployments] Your organization is responsible for: * generating stable one-way aliases; * protecting the alias-to-person mapping; * applying the same alias to every browser and device for that person; * keeping tag paths broad enough that a group cannot be narrowed to one person; and * removing or rotating aliases when your identity lifecycle requires it. Avanoo receives the alias but not the mapping that reveals the person behind it. Tags are the most common way a pseudonymous deployment leaks. A tag path that applies to a handful of people identifies them by elimination, and the alias never has to be broken for that to happen. Apply tags to large groups only, and treat any breakdown that isolates a small team as identifying. Anyone with read access to your directory can resolve an alias back to a person, because the alias is stored on the user object. That is expected — it is what keeps the mapping under your control. The requirement is that Avanoo, and Avanoo users without directory access, cannot. ### For all deployments [#for-all-deployments] Document the selected mode, the reason for choosing it, and the administrators who can change the associated policies. Review the mode when your privacy requirements, directory model, or analytics needs change. Use the public [identity mode comparison](/docs/deployment/identity/compare) to explain the choice to stakeholders. After platform access is provisioned, the implementation team can use the deployment instructions for the selected mode. The data inventory and the hosting posture sit on [What Avanoo collects](/docs/security-and-privacy/data-collection-overview) and [Hosting, security, and compliance](/docs/security-and-privacy/hosting-security-and-compliance). # Compare Identified and Pseudonymous modes (/docs/deployment/identity/compare) Avanoo can attribute browser activity to a real identity or to an alias controlled by your organization. Both modes support accurate per-user analytics, grouping, and reconciliation across browsers and devices. The difference is whether Avanoo receives the real identity. ## At a glance [#at-a-glance] | | Identified | Pseudonymous | | --------------------------- | ------------------------------------------- | ------------------------------------------------------ | | Identity sent to Avanoo | The user’s real email address | A stable alias generated by your organization | | Per-user analytics | Available under the real identity | Available under the alias | | Groups and segments | Available | Available | | Cross-device reconciliation | Available | Available | | Employee privacy | Real identities are visible in Avanoo | Avanoo cannot resolve the alias to the person | | Main responsibility | Keep directory and access controls accurate | Keep the alias generation and private mapping accurate | ## Choose Identified when [#choose-identified-when] Identified mode is usually the simplest choice when your organization already manages user identities centrally and administrators need named-user visibility. It is a good fit when: * your directory can provide the user’s email address; * administrators need to investigate activity by person; * groups are already managed in an identity provider or directory; and * your organization’s privacy policy allows the service to receive real identities. ## Choose Pseudonymous when [#choose-pseudonymous-when] Pseudonymous mode is a good fit when you need accurate per-user and group analytics but want to keep the relationship between an employee and their identity on your side. It requires more preparation: your organization generates and manages the aliases and owns the private mapping behind them. Avanoo receives the alias and any configured tags, but never the mapping that reveals the person. See [usage modes and privacy](/docs/security-and-privacy/usage-modes-and-privacy) for the responsibilities your organization takes on in each mode. ## What about Anonymous mode? [#what-about-anonymous-mode] Anonymous mode attributes activity only to a device signature and does not provide per-user analytics, groups, cross-device reconciliation, or nudging. It is a legacy mode and should not be selected for a new deployment without confirming the use case with Avanoo. ## Next steps [#next-steps] Use this comparison to choose an identity mode before starting deployment. Once your organization has platform access, the implementation team can follow the deployment instructions for the selected mode. After platform access is provisioned, open the [documentation home](/docs) to choose the identity method available in your deployment context. When managed browser storage is selected, it shows the deployment procedures that match your policy delivery options and identity mode. Follow the console you actually use. Managed browser storage includes Group Policy. Review the [privacy model](/docs/security-and-privacy/usage-modes-and-privacy) for more detail about data handling and organizational responsibilities. # Documentation Avanoo (/fr/docs) Bienvenue dans la documentation Avanoo. Utilisez ces guides pour préparer votre organisation, déployer l'extension de navigateur, comprendre notre modèle de confidentialité et exploiter Avanoo en production. ## Commencer par le bon parcours [#commencer-par-le-bon-parcours] * [Vue d'ensemble](/docs/getting-started/what-is-avanoo) présente la plateforme et les premières étapes pour un administrateur. * [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview) est l'inventaire des données à transmettre à un DPO ou à une revue fournisseur. * [Hébergement, sécurité et conformité](/docs/security-and-privacy/hosting-security-and-compliance) couvre la résidence des données, les sous-traitants, le chiffrement et les certifications. Si vous devez choisir la façon dont Avanoo identifie les utilisateurs, commencez par la [comparaison des modes d'identité](/docs/deployment/identity/compare). L'extension se déploie par stratégie de groupe (GPO), Intune, Google Workspace ou un équivalent. # Accéder à la documentation (/fr/docs/getting-started/accessing-documentation) La documentation client est rattachée à votre organisation Avanoo. Le contenu que vous voyez peut dépendre de l'étape du cycle de vie de votre organisation et des fonctionnalités activées. ## Administrateurs clients [#administrateurs-clients] Connectez-vous à la plateforme Avanoo avec le compte de votre organisation, puis ouvrez le lien de documentation depuis la plateforme. La session de documentation utilise la même identité que la plateforme : vous n'avez pas besoin d'un second mot de passe. ## Partenaires de mise en œuvre et MSP [#partenaires-de-mise-en-œuvre-et-msp] Si un partenaire de mise en œuvre a besoin de conseils de déploiement ou d'intégration, invitez-le dans l'organisation Avanoo concernée depuis la plateforme. Il obtient ainsi le bon périmètre, sans envoyer de documents de déploiement propres à l'organisation sous forme de fichiers hors ligne. Une fois connecté à la documentation avec une organisation, utilisez **Partager un lien** dans la barre de compte. Envoyez ce lien à un technicien qui n'a pas encore d'accès à la plateforme. Traitez-le comme un identifiant : utilisez-le uniquement pour la mission prévue et ne le transmettez pas. ## Si un guide est absent [#si-un-guide-est-absent] Une page absente peut signifier que : * votre organisation n'a pas droit à cette fonctionnalité ; * le guide n'est disponible que pendant la mise en route ; ou * votre administrateur n'a pas encore provisionné l'accès nécessaire. Si le guide reste indisponible, contactez votre administrateur Avanoo via la plateforme. # Qu'est-ce qu'Avanoo ? (/fr/docs/getting-started/what-is-avanoo) Avanoo aide les organisations à comprendre et à améliorer leur usage des applications SaaS. La plateforme rassemble des signaux d'usage, d'identité, de sécurité et de gouvernance afin que les équipes informatiques puissent décider en connaissance de cause pour leur environnement technologique. ## Ce que vous pouvez faire avec Avanoo [#ce-que-vous-pouvez-faire-avec-avanoo] * Découvrir quelles applications SaaS et extensions de navigateur sont utilisées. * Repérer les licences non utilisées et les pistes de réduction des coûts. * Comprendre les risques de sécurité et de confidentialité de l'environnement SaaS. * Fournir aux administrateurs des rapports et un contexte opérationnel utiles. * Aider les collaborateurs à s'orienter vers les applications approuvées grâce à des conseils affichés dans le navigateur. L'extension de navigateur collecte les métadonnées nécessaires à ces fonctionnalités. Les signaux réellement disponibles pour votre organisation dépendent des modules et des paramètres de surveillance activés pour votre environnement. Pour une revue fournisseur, DPO ou sécurité, commencez par [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview) et [Hébergement, sécurité et conformité](/docs/security-and-privacy/hosting-security-and-compliance). ## À propos du déploiement [#à-propos-du-déploiement] Avanoo se déploie en général par stratégie de groupe (GPO), Intune, Google Workspace ou un équivalent. Avant de choisir une procédure de déploiement, consultez la [comparaison des modes d'identité](/docs/deployment/identity/compare). Une fois l'accès à la plateforme obtenu, votre équipe de mise en œuvre recevra les instructions de déploiement correspondant à l'étape et au mode d'identité retenu. # Ce qu'Avanoo collecte (/fr/docs/security-and-privacy/data-collection-overview) Avanoo cartographie les usages SaaS et IA à partir du navigateur. La solution est conçue pour donner à l'informatique, à la sécurité et aux achats une visibilité utile **sans collecter le contenu de l'activité observée**. Cette page est l'inventaire des données à transmettre à un DPO, un RSSI, un CSE ou un acheteur. L'hébergement, le chiffrement, les sous-traitants et les certifications sont sur [Hébergement, sécurité et conformité](/docs/security-and-privacy/hosting-security-and-compliance). ## Le principe en une phrase [#le-principe-en-une-phrase] Avanoo collecte des **métadonnées** (quelle application professionnelle a été utilisée, quand, et selon les règles d'identité que vous avez choisies), pas les courriels, les fichiers, les invites, les mots de passe, ni la navigation hors des applications que vous autorisez. Il n'y a ni agent sur le système d'exploitation, ni proxy réseau. Le seul composant installé sur un poste est une extension de navigateur, déployée par votre organisation sur les postes professionnels. ## Deux contrôles précèdent chaque événement [#deux-contrôles-précèdent-chaque-événement] Rien n'est produit tant que ces deux conditions ne sont pas réunies. 1. **Une liste d'inclusion de domaines.** L'extension ne traite que les domaines enregistrés par votre organisation. Toute autre navigation est ignorée avant traitement : aucun événement n'est créé, et il n'existe aucun moyen de reconstituer cette visite a posteriori. La liste est consultable et exportable depuis la plateforme. Le catalogue initial proposé par Avanoo ne contient que des applications professionnelles — pas la messagerie personnelle, les réseaux sociaux grand public, les services bancaires, de santé, syndicaux ou de recherche d'emploi. Vous restez maître de la liste, y compris pour des URL spécifiques à des applications on-premise ouvertes dans le navigateur. 2. **Des interrupteurs par capacité, désactivés par défaut.** Chaque capacité de surveillance a son propre interrupteur au niveau de l'organisation. Une activation ou une désactivation s'applique à l'ensemble du parc sans mise à jour de l'extension. Les changements sont journalisés. Le mode d'identité (Identifié, Pseudonymisé ou Anonyme) détermine **à qui un événement est rattaché**. Il n'élargit pas ce que l'extension est autorisée à observer. ## Sources de données [#sources-de-données] | Source | Ce qu'elle apporte | Obligatoire ? | | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | Extension de navigateur (Chrome, Edge, Brave, Firefox) | Métadonnées d'usage, d'authentification, d'IA, de MCP, d'inventaire d'extensions et d'activité des données, depuis les navigateurs professionnels | Oui, pour la découverte | | Ingestion d'annuaire (Microsoft Entra, Google Workspace, Keycloak) | Utilisateurs, groupes ou unités d'organisation, et éventuellement le contexte des connexions ou des consentements OAuth | Optionnelle | | SCIM ou CSV | Listes d'utilisateurs et de groupes lorsqu'un connecteur d'annuaire n'est pas utilisé | Optionnelle | | Catalogue d'applications | Métadonnées de conformité sur les applications elles-mêmes (certifications, région d'hébergement, politique de rétention). Il s'agit d'un référentiel produit, pas de données de collaborateurs | Inclus | Les intégrations d'annuaire, SCIM et CSV enrichissent l'identité et le regroupement. Elles ne remplacent pas l'extension, et ce ne sont pas des sous-traitants d'Avanoo : ce sont des systèmes que vous opérez déjà. ## Données collectées [#données-collectées] Le tableau ci-dessous est l'inventaire. Une ligne ne s'applique que si la capacité correspondante est activée pour votre organisation. | Capacité | Forme conservée | Finalité typique | | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Domaine d'application dans la liste d'inclusion | Domaine enregistrable uniquement — pas le chemin à l'intérieur du site | Cartographie SaaS et Shadow IT | | Horodatage de visite | Horodatage, puis agrégé en usage mensuel | Fréquence d'usage, rapprochement des licences | | Authentifié vs visité | Booléen | Distinguer une session réelle d'un passage | | Signature d'installation du navigateur | Identifiant technique stable de cette installation, pas d'une personne | Dénombrer les navigateurs distincts ; relier les événements d'une même installation | | Identité professionnelle ou alias | Adresse professionnelle réelle, alias contrôlé par l'organisation, ou aucune — voir les modes d'identité ci-dessous | Rattacher l'usage à une personne ou à une cohorte | | Métadonnées de connexion | Type de méthode, succès ou échec, échecs consécutifs | Détecter une attaque par bourrage d'identifiants, pas la performance d'un collaborateur | | Métadonnées MFA | Type de second facteur observé | Mesurer la couverture MFA | | Métadonnées SSO / OAuth / SAML | Fournisseur d'identité, application cible, permissions demandées | Vérifier la politique SSO et les délégations à des tiers | | Passkeys / WebAuthn | Type d'authentificateur uniquement — le secret n'est jamais capturé | Inventorier l'authentification résistante au hameçonnage | | Réutilisation et robustesse des mots de passe | Empreinte irréversible, propre à l'utilisateur, calculée dans le navigateur. Avanoo ne reçoit jamais le mot de passe ni l'empreinte de comparaison | Repérer des identifiants réutilisés entre applications | | Extensions de navigateur installées | Nom, version, éditeur, permissions, état | Inventaire de la surface d'attaque du navigateur | | Usage de l'IA | Nom du service, horodatage, **nombre** et **longueur** des invites, compte entreprise vs personnel | Cartographie du Shadow AI sans le contenu des invites | | Connexions MCP | Nom du serveur, nom de l'outil, signaux d'autorisation | Voir quels clients d'IA ont reçu la capacité d'agir | | Métadonnées de fichiers et de transferts | Nom, taille, type MIME, domaine de destination | Investiguer les envois vers un stockage ou une IA non sanctionnés | | Presse-papiers et glisser-déposer | Longueur du texte et nombre de fichiers, pas le contenu | Signal de mouvement de données | | Libellés DLP locaux (optionnel) | **Libellés et comptages** des détecteurs uniquement, calculés dans le navigateur | Signaler des catégories de données sensibles sans envoyer le texte | | Réponses aux campagnes | Réponses volontaires aux questions envoyées par vos administrateurs | Adoption et sentiment, mode Identifié uniquement | Les fiches du catalogue sur les applications (score de sécurité, certifications, pays de traitement) ne sont pas des données à caractère personnel. ## Ce qui ne quitte jamais le navigateur — et ce qui n'est jamais collecté [#ce-qui-ne-quitte-jamais-le-navigateur--et-ce-qui-nest-jamais-collecté] | Jamais collecté ni transmis | Précision | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Contenu** des courriels, messages ou documents | La structure d'une page peut être lue en mémoire pour reconnaître un écran de connexion. Le texte affiché n'est ni conservé ni transmis | | **Contenu** des invites ou réponses d'IA | Seuls un compteur et une longueur en caractères quittent le navigateur | | **Contenu** des fichiers | Nom, taille, type et domaine uniquement | | **Contenu** du presse-papiers | Longueur et type uniquement | | Mots de passe | Transformés immédiatement dans le navigateur. Avanoo ne reçoit jamais le clair ni une empreinte réversible | | Frappes clavier, captures d'écran, caméra ou micro | Non implémentés | | Historique de navigation | Ni lu, ni conservé | | Navigation hors liste d'inclusion | Aucun événement n'est créé | | Adresses personnelles en entier | Lorsqu'une adresse est classée personnelle, la partie identifiante est supprimée dans le navigateur avant tout enregistrement (`jane.doe@gmail.com` devient `@gmail.com`) | | Supervision en temps réel des collaborateurs | Les événements sont remontés de façon asynchrone, par lots. Il n'existe aucun écran de supervision en direct. Les messages contextuels dans le navigateur sont calculés localement à partir de la politique déjà déployée | | Score individuel de performance | Les finalités sont la sécurité, la conformité, la gestion du parc et la sensibilisation — pas l'évaluation RH | Avanoo ne revend pas les données clients, ne les utilise pas à des fins publicitaires et n'entraîne pas de modèles de fondation avec elles. Les données servent exclusivement à la fourniture du service contractuel. ## Modes d'identité [#modes-didentité] L'identité est choisie au déploiement et peut être modifiée depuis la plateforme sans redéployer l'extension. | Mode | Ce qu'Avanoo reçoit | Ce que vous voyez | | ---------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Identifié** | L'identité professionnelle réelle de l'utilisateur | Analyses nominatives, groupes réels, réconciliation entre postes, accompagnement individuel | | **Pseudonymisé** | Un alias stable généré par votre organisation. Avanoo ne reçoit jamais la correspondance vers la personne | Analyses par utilisateur et par groupe sous l'alias | | **Anonyme** | Une signature de poste uniquement | Usage grossier par application. Mode historique — ne le retenez pas pour un nouveau déploiement sans confirmer le cas d'usage avec Avanoo | Aucun mode d'identité ne modifie la liste « jamais collecté » ci-dessus. Utilisez la [comparaison des modes d'identité](/docs/deployment/identity/compare) avec les parties prenantes, puis le [modèle de confidentialité](/docs/security-and-privacy/usage-modes-and-privacy) pour les responsabilités que chaque mode fait peser sur votre organisation. ## Catalogue d'applications [#catalogue-dapplications] Le même catalogue est utilisé par l'extension de navigateur, le rapprochement SSO et les signaux d'annuaire optionnels : * plus de 110 000 applications professionnelles, mises à jour chaque semaine (en particulier les nouveaux outils d'IA) ; * personnalisable par organisation, y compris des URL spécifiques pour des applications on-premise ouvertes dans le navigateur ; * exportable depuis la plateforme, afin qu'un DPO ou un CSE puisse voir exactement quels domaines sont dans le périmètre. ## Conservation [#conservation] Confirmez les durées dans votre contrat. Le modèle par défaut est le suivant : | Données | Durée de conservation | | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Horodatages de visite des applications | Agrégés en usage mensuel sous quelques jours. Passé ce délai, « qui a ouvert quelle application à 14 h 32 mardi » n'existe plus | | Événements de sécurité et de mouvement de données (connexions, délégations OAuth/SAML, MCP, fichiers, presse-papiers) | Conservés sous forme unitaire pendant la durée contractuelle, parce que l'investigation d'un incident exige l'événement précis. Données d'usage et de connexion : **12 mois au maximum** | | Agrégats mensuels | Durée du contrat | | Journaux d'accès à la plateforme et de modification de configuration | Au moins 12 mois | | Réponses aux campagnes | Durée du contrat, sauf durée plus courte convenue | | Départ d'un collaborateur | Suppression sur instruction du client | | Fin de contrat | Restitution ou destruction sur instruction écrite ; à défaut, destruction dans l'année qui suit la fin du DPA | ## Rôles [#rôles] Le **client est responsable de traitement**. Avanoo est **sous-traitant** au titre d'un Data Processing Agreement (article 28 du RGPD). La base légale, l'information des personnes, la consultation du CSE et le registre des traitements relèvent du client. Avanoo assiste pour les demandes d'exercice des droits et les analyses d'impact, avec les informations dont il dispose. ## Pages associées [#pages-associées] * [Hébergement, sécurité et conformité](/docs/security-and-privacy/hosting-security-and-compliance) — résidence des données, chiffrement, sous-traitants, certifications. * [Modes d'usage et confidentialité](/docs/security-and-privacy/usage-modes-and-privacy) — responsabilités en mode Identifié et en mode Pseudonymisé. * [Comparer les modes d'identité](/docs/deployment/identity/compare) — choix à présenter aux parties prenantes. # Hébergement, sécurité et conformité (/fr/docs/security-and-privacy/hosting-security-and-compliance) Cette page couvre la résidence des données, les mesures de sécurité, les sous-traitants et la posture de conformité. Pour l'inventaire des données elle-même, commencez par [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview). ## Hébergement et résidence [#hébergement-et-résidence] Avanoo est un SaaS multi-tenant. L'application, les bases de données et les sauvegardes s'exécutent sur **Amazon Web Services** dans l'Espace économique européen : * **Principal :** AWS Europe (Paris), `eu-west-3` * **Redondance :** AWS Europe (Francfort), `eu-central-1` Les données clients sont stockées et traitées dans ces régions européennes. L'exécution standard du service ne transfère pas les données d'usage hors de l'EEE. La bascule entre Paris et Francfort est documentée et manuelle. Avanoo n'exploite pas de datacenter en propre. Il n'existe pas de chemin d'hébergement de production chez OVH ni Google Cloud. L'inférence d'IA pour l'assistant optionnel intégré au produit utilise **AWS Bedrock dans l'UE uniquement**. Le schéma ci-dessous décrit l'architecture de production dans la région principale Paris. Francfort assure la redondance et n'y figure pas. ![Architecture de production Avanoo sur AWS eu-west-3 (Paris). L'application web app.avanoo.ai authentifie les administrateurs via Clerk vers EC2. Les extensions de navigateur envoient l'identifiant d'application, l'e-mail et l'identifiant d'extension en HTTPS vers API Gateway, un autorisateur Lambda, SQS et Lambda. Des Lambda planifiées appellent Microsoft Graph et d'autres API SaaS. Les données sont écrites dans S3 et dans RDS, à l'intérieur d'un VPC, y compris une instance RDS dédiée au client.](/images/security/infrastructure-eu-west-3.png) ## Chiffrement et clés [#chiffrement-et-clés] | Couche | Mesure | | ----------- | ------------------------------------------------------------------------------------------------------------- | | En transit | TLS 1.2 au minimum. Certificats émis et renouvelés via AWS Certificate Manager | | Au repos | AES-256 sur RDS (PostgreSQL) et S3 (SSE-S3 ou SSE-KMS) | | Clés | AWS KMS, pas de gestion locale de clés, accès restreint et journalisé | | Sauvegardes | Instantanés RDS chiffrés (7 jours par défaut) et objets S3 versionnés, avec tests de restauration périodiques | ## Isolation et accès [#isolation-et-accès] * Les environnements clients sont **isolés logiquement** en base et dans les journaux. Aucune mutualisation applicative des données entre tenants. * L'accès au tableau de bord se fait par comptes nominatifs via SSO, avec trois rôles : lecture, analyse et administration. L'authentification forte est gérée par le fournisseur d'identité du client. * Côté Avanoo : moindre privilège, comptes IAM nominatifs avec MFA, AWS SSO. L'accès direct aux bases est interdit hors maintenance. * Les accès aux données, les échecs d'accès et les comportements suspects sont journalisés (AWS CloudTrail et GuardDuty). Les journaux sont conservés au moins 12 mois. ## Sous-traitants [#sous-traitants] Distinguez trois choses que les questionnaires fournisseurs mélangent souvent. **Traitants des données clients dans le service** | Sous-traitant | Rôle | Localisation | | ------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Amazon Web Services | Héberge l'application, les bases, le stockage objet et les sauvegardes | EEE (Paris, Francfort) | | Clerk | Authentifie les **administrateurs** du tableau de bord Avanoo (SAML, OIDC, SCIM) | Voir l'annexe du DPA. Clerk n'identifie pas les collaborateurs dans l'extension de navigateur | | AWS Bedrock | Assistant optionnel intégré au produit | Région UE uniquement | La liste contractuelle, les durées de conservation et le préavis en cas de changement figurent en annexe du Data Processing Agreement. Avanoo informe les clients avant d'ajouter ou de remplacer un sous-traitant. Les transferts hors EEE, s'il y en a, s'appuient sur des garanties adaptées au RGPD, notamment les clauses contractuelles types de la Commission européenne. **Pas des sous-traitants d'Avanoo** * **Vos fournisseurs d'identité** (Microsoft Entra, Google Workspace, Okta et autres) restent vos systèmes. Les connecter est optionnel et sous votre contrôle. * **GitHub** est le gestionnaire de versions d'Avanoo. Il n'héberge pas les données de vos tenants. * **Google Workspace** et **Vanta** sont des outils internes d'Avanoo (collaboration et conformité). Ils ne traitent pas les événements d'usage de vos collaborateurs. ## RGPD [#rgpd] | Sujet | Position | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Rôles | Client = responsable de traitement. Avanoo = sous-traitant (DPA, article 28 du RGPD) | | DPO | DPO externalisé (cabinet Acmai). Contact **[privacy@avanoo.ai](mailto:privacy@avanoo.ai)** ou **[dpo@avanoo.ai](mailto:dpo@avanoo.ai)** | | Contact sécurité | **[security@avanoo.ai](mailto:security@avanoo.ai)** (RSSI) | | Minimisation | Métadonnées uniquement ; liste d'inclusion ; interrupteurs par capacité désactivés par défaut ; voir [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview) | | Information des personnes, AIPD, CSE | Responsabilité du client. Avanoo fournit l'inventaire et l'assistance | | Notification de violation | Avanoo notifie le client dès que possible par courriel et coopère au titre des articles 33 et 34 | | Fin de contrat | Un mois pour demander la restitution ou la destruction ; à défaut, destruction dans l'année qui suit la fin du DPA | Avanoo est une société française : Avanoo SAS, 54 rue du Faubourg Poissonnière, 75010 Paris, SIREN 925 197 519. ## Certifications [#certifications] Avanoo **n'est pas** aujourd'hui certifié ISO 27001, ISO 27701, SOC 2, SecNumCloud, ni HDS pour son propre service. Ce qui est en place : * Une politique de sécurité des systèmes d'information (PSSI) documentée, disponible en PDF sur demande. * Un test d'intrusion externe indépendant. * Des revues de sécurité internes. * Un programme **ISO/IEC 27001** (outillage via Vanta), avec une certification visée pour **2027**. Le suivi SOC 2 relève du même programme ; Avanoo n'est pas certifié SOC 2 aujourd'hui. * Un hébergement sur AWS, qui détient ses propres attestations ISO 27001, SOC et, en France, **HDS**. Les questions d'infrastructure portant sur HDS ou SecNumCloud se rapportent donc au prestataire d'hébergement, pas à l'application Avanoo. ## Continuité [#continuité] Les sauvegardes sont automatisées et chiffrées. Les tests de restauration sont périodiques. Un plan de continuité et de reprise couvre la bascule entre Paris et Francfort, avec des exercices de crise annuels. ## Documents disponibles sur demande [#documents-disponibles-sur-demande] Transmettez ceux-ci à un prospect, un DPO ou un CSE plutôt que de les paraphraser : * Data Processing Agreement (contrat de sous-traitance, y compris l'annexe des sous-traitants) * Cette documentation : [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview) et la présente page * Politique de confidentialité : [avanoo.ai/legal/privacy-policy](https://avanoo.ai/legal/privacy-policy) * Politique de sécurité des systèmes d'information (PSSI) et plan d'assurance sécurité * Rapport de test d'intrusion externe, sous NDA * Dossier type CSE, lorsque le déploiement a lieu en France Pour un paramétrage précis (quels interrupteurs sont actifs sur un tenant donné), l'administrateur du client exporte la configuration depuis la plateforme, ou s'adresse à son interlocuteur Avanoo. # Modes d'usage et confidentialité (/fr/docs/security-and-privacy/usage-modes-and-privacy) Avanoo propose différents niveaux de visibilité de l'identité, afin que chaque organisation puisse choisir le bon équilibre entre analyse et confidentialité. ## Le spectre de la confidentialité [#le-spectre-de-la-confidentialité] * **Anonyme** fournit le moins d'informations d'identité et le moins de fonctionnalités par utilisateur. C'est un mode historique, réservé aux déploiements très restreints ou transitoires. * **Pseudonymisé** fournit des analyses précises par utilisateur et par groupe à l'aide d'alias, tout en conservant la correspondance avec l'identité réelle au sein de votre organisation. * **Identifié** fournit la vue nominative la plus riche et utilise les identités réelles issues de votre répertoire ou de votre fournisseur d'identité. Aucun mode d'identité ne modifie ce que l'extension est autorisée à collecter. Les capacités de surveillance sont contrôlées séparément par les paramètres de l'organisation. ## Responsabilités en matière de confidentialité [#responsabilités-en-matière-de-confidentialité] ### Pour les déploiements Identifié [#pour-les-déploiements-identifié] Avant de déployer le mode Identifié, confirmez que votre organisation est autorisée à transmettre des identités réelles à Avanoo. Limitez l'appartenance au répertoire et l'accès administrateur aux personnes qui en ont besoin. ### Pour les déploiements Pseudonymisé [#pour-les-déploiements-pseudonymisé] Votre organisation est responsable de : * générer des alias stables à sens unique ; * protéger la correspondance alias ↔ personne ; * appliquer le même alias à tous les navigateurs et postes de cette personne ; * veiller à ce que les chemins de tags couvrent des groupes suffisamment larges pour qu'aucun ne se réduise à une seule personne ; et * supprimer ou faire tourner les alias lorsque votre cycle de vie des identités l'exige. Avanoo reçoit l'alias, mais pas la correspondance qui révèle la personne derrière. Les tags sont la première source de fuite d'un déploiement pseudonymisé. Un chemin de tags qui ne s'applique qu'à quelques personnes les identifie par élimination, sans qu'il soit nécessaire de casser l'alias. N'appliquez les tags qu'à des groupes larges, et considérez comme identifiante toute ventilation qui isole une petite équipe. Toute personne ayant un accès en lecture à votre répertoire peut remonter d'un alias à une personne, puisque l'alias est stocké sur l'objet utilisateur. C'est attendu : c'est ce qui maintient la correspondance sous votre contrôle. L'exigence porte sur Avanoo, et sur les utilisateurs d'Avanoo qui n'ont pas accès au répertoire. ### Pour tous les déploiements [#pour-tous-les-déploiements] Documentez le mode retenu, la raison de ce choix et les administrateurs autorisés à modifier les politiques associées. Réexaminez le mode lorsque vos exigences de confidentialité, votre modèle de répertoire ou vos besoins d'analyse évoluent. Utilisez la [comparaison des modes d'identité](/docs/deployment/identity/compare) pour expliquer le choix aux parties prenantes. Une fois l'accès à la plateforme provisionné, l'équipe de mise en œuvre peut utiliser les instructions de déploiement du mode retenu. L'inventaire des données et la posture d'hébergement sont sur [Ce qu'Avanoo collecte](/docs/security-and-privacy/data-collection-overview) et [Hébergement, sécurité et conformité](/docs/security-and-privacy/hosting-security-and-compliance). # Comparer les modes Identifié et Pseudonymisé (/fr/docs/deployment/identity/compare) Avanoo peut attribuer l'activité de navigation à une identité réelle ou à un alias contrôlé par votre organisation. Les deux modes permettent des analyses par utilisateur précises, des regroupements et une réconciliation entre navigateurs et postes. La différence porte sur le fait qu'Avanoo reçoive ou non l'identité réelle. ## En un coup d'œil [#en-un-coup-dœil] | | Identifié | Pseudonymisé | | ---------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Identité transmise à Avanoo | L'adresse e-mail réelle de l'utilisateur | Un alias stable généré par votre organisation | | Analyses par utilisateur | Disponibles sous l'identité réelle | Disponibles sous l'alias | | Groupes et segments | Disponibles | Disponibles | | Réconciliation entre postes | Disponible | Disponible | | Confidentialité des collaborateurs | Les identités réelles sont visibles dans Avanoo | Avanoo ne peut pas relier l'alias à la personne | | Responsabilité principale | Maintenir l'exactitude du répertoire et des contrôles d'accès | Maintenir l'exactitude de la génération des alias et de la correspondance privée | ## Choisir Identifié quand [#choisir-identifié-quand] Le mode Identifié est généralement le choix le plus simple lorsque votre organisation gère déjà les identités de façon centralisée et que les administrateurs ont besoin d'une visibilité nominative. Il convient bien lorsque : * votre répertoire peut fournir l'adresse e-mail de l'utilisateur ; * les administrateurs doivent enquêter sur l'activité par personne ; * les groupes sont déjà gérés dans un fournisseur d'identité ou un répertoire ; et * la politique de confidentialité de votre organisation autorise le service à recevoir des identités réelles. ## Choisir Pseudonymisé quand [#choisir-pseudonymisé-quand] Le mode Pseudonymisé convient bien lorsque vous avez besoin d'analyses précises par utilisateur et par groupe, tout en gardant de votre côté le lien entre un collaborateur et son identité. Il demande davantage de préparation : votre organisation génère et gère les alias, et détient la correspondance privée qui les sous-tend. Avanoo reçoit l'alias et les tags configurés, mais jamais la correspondance qui révèle la personne. Consultez [modes d'usage et confidentialité](/docs/security-and-privacy/usage-modes-and-privacy) pour les responsabilités que votre organisation assume dans chaque mode. ## Et le mode Anonyme ? [#et-le-mode-anonyme-] Le mode Anonyme attribue l'activité uniquement à une signature de poste et ne fournit ni analyses par utilisateur, ni groupes, ni réconciliation entre postes, ni sollicitations. C'est un mode historique : ne le retenez pas pour un nouveau déploiement sans avoir validé le cas d'usage avec Avanoo. ## Étapes suivantes [#étapes-suivantes] Utilisez cette comparaison pour choisir un mode d'identité avant de commencer le déploiement. Une fois l'accès à la plateforme provisionné, l'équipe de mise en œuvre peut suivre les instructions de déploiement du mode retenu. Après le provisionnement de l'accès à la plateforme, ouvrez l'[accueil de la documentation](/docs) pour choisir la méthode d'identité disponible dans votre contexte de déploiement. Lorsque le stockage géré du navigateur est retenu, il affiche les procédures de déploiement qui correspondent à vos options de distribution de politiques et à votre mode d'identité. Suivez la console que vous utilisez réellement. Le stockage géré du navigateur inclut la stratégie de groupe. Consultez le [modèle de confidentialité](/docs/security-and-privacy/usage-modes-and-privacy) pour plus de détails sur le traitement des données et les responsabilités organisationnelles.