Livrables possibles
Livrables possibles
- Audit UX, performance et sécurité
- Architecture ou refonte de site
- Durcissement, sauvegardes et supervision
- Plan de maintenance et d’amélioration continue
05 / 06
Cyber · IA · Intelligence numérique
Web sécurisé & performance
Concevoir ou renforcer un service web rapide, accessible, maintenable et cohérent avec le niveau de risque.
La qualité d’un site se mesure à sa capacité à informer, rassurer, convertir et rester disponible. Nous relions architecture, expérience, performance, sécurité, hébergement et maintenance dans une même feuille de route.
05
Ce que la mission doit vous apporter
- 01Une expérience plus claire sur ordinateur et mobile
- 02Une base technique plus rapide et plus robuste
- 03Une maintenance réaliste qui évite la dette invisible
Comment se déroule la mission
Comment se déroule la mission
Un déroulé court, explicite et adapté au niveau de sensibilité du sujet.
- 01
Cadrage
Nous précisons la décision à éclairer, les actifs concernés, les contraintes, les sources autorisées et le niveau de confidentialité.
- 02
Investigation
La collecte et l’analyse suivent un périmètre validé. Les faits, hypothèses et zones d’incertitude restent clairement séparés.
- 03
Priorisation
Chaque constat est évalué selon sa fiabilité, son impact probable et l’effort nécessaire pour agir.
- 04
Restitution
Vous recevez une synthèse lisible, les éléments de preuve utiles et une feuille de route directement exploitable.
Situations fréquentes
Situations fréquentes
- Site vieillissant ou difficile à faire évoluer
- Temps de chargement, conversion ou accessibilité insuffisants
- Besoin d’un socle web sobre et sécurisé
Comment vérifier le résultat de la mission ?
Ces repères servent à convenir d’une restitution vérifiable. Les contrôles et les seuils sont adaptés au périmètre retenu ; les exemples ci-dessous ne sont pas des résultats clients.
| Objet du contrôle | Preuve à demander | Décision permise |
|---|---|---|
| Parcours essentiel | Début, étapes, confirmation et récupération d’erreur ; essais sur mobile, au clavier et avec zoom. | Livrer quand la tâche se termine, y compris après une erreur corrigeable. |
| Performance vécue | LCP, INP et CLS au 75e percentile, période, type d’appareil, périmètre URL/origine et volume disponible ; mesures laboratoire séparées. | Prioriser le goulot observé et signaler les conclusions limitées par un faible volume. |
| Accessibilité | Périmètre, pages et états testés, critères examinés, résultats manuels et limites des outils automatiques. | Corriger les barrières documentées sans déduire une conformité globale d’un seul score. |
| Maintenance et reprise | Dépendances maintenues, accès, procédure de mise à jour, sauvegarde et restauration exercée. | Attribuer les contrôles récurrents et vérifier la continuité après livraison. |
Mettre la décision à l’épreuve
Un parcours rapide qui échoue après une erreur
Un formulaire mobile répond vite dans un test de laboratoire. Lors d’un essai fonctionnel, une erreur de validation efface pourtant les champs déjà renseignés.
Cas pédagogique fictif. Les chiffres servent à expliquer un raisonnement ; ils ne représentent ni des résultats clients ni des seuils imposés par une norme.
- étapes dans le parcours
- 5
- erreur récupérable testée
- 1
- champ conservé après cette erreur
- 0
| Choix envisagé | Ce qui manque ou ce qui le justifie |
|---|---|
| Livrer grâce au seul score de vitesse | La rapidité ne démontre pas que la tâche aboutit. |
| Revoir toute la charte graphique | Le défaut observé concerne d’abord la conservation de la saisie et la reprise. |
| Corriger puis rejouer le parcours complet | Vérifier les champs préservés, l’erreur compréhensible et la confirmation finale. |
Lire l’arbitrage et la prochaine vérification
La priorité proposée est la reprise après erreur. Le contrôle repart du début, provoque l’erreur, corrige la valeur puis vérifie la confirmation. Le test inclut le clavier et une fenêtre de 320 pixels CSS pour repérer les obstacles de navigation et de lecture.
La vérification suivante
Rejouer la tâche prioritaire au clavier, avec zoom et sur mobile ; provoquer une erreur puis vérifier la confirmation finale. Comparer les mesures de terrain sur des populations comparables et conserver les limites des tests de laboratoire.
Ce que ce cas ne démontre pas
La réussite de ce scénario ne constitue ni un audit complet d’accessibilité ni une preuve de performance pour tous les visiteurs.
Références et portée
- Google / web.dev — Web Vitals
Les Core Web Vitals couvrent chargement, interaction et stabilité visuelle ; leur appréciation utilise le 75e percentile des visites. Ils ne couvrent pas à eux seuls toute la qualité d’un service.
- W3C — WCAG-EM Overview
La méthode organise périmètre, exploration, échantillon représentatif, évaluation et restitution. Le tableau ci-dessus prépare des contrôles ; il n’est pas une déclaration de conformité WCAG.
- W3C — Understanding Reflow (WCAG 2.2, 1.4.10)
Le critère traite notamment de la redistribution du contenu à une largeur équivalente à 320 pixels CSS, avec des exceptions pour les contenus exigeant deux dimensions.
Références consultées le 15 octobre 2026.
Avant la mission
Cadrer une décision utile
La revue suit les tâches importantes du site et les contraintes de leur exploitation. Elle examine ensemble contenu, interface, accessibilité, vitesse, sécurité et capacité de maintenance afin de prioriser les corrections qui améliorent le service complet. La vérification porte sur le parcours complet : trouver une réponse, comprendre l’offre, agir et recevoir une confirmation exploitable. Elle relie accessibilité au clavier, affichage mobile, performance réelle, erreurs de formulaire et sécurité des échanges. Chaque correction conserve une condition de réussite observable et un scénario de contrôle après publication, afin que le gain technique corresponde à une tâche réellement terminée.
Informations à réunir
- Parcours essentiels et publics concernés
- Données de performance disponibles et retours utilisateurs
- Architecture, hébergement et cycle de publication
Décisions à préparer
- Corriger le socle existant ou préparer une refonte ?
- Quels composants créent des barrières communes ?
- Comment valider la reprise après un incident ?
- Un formulaire, une API ou un email permet-il réellement de terminer et confirmer la tâche ?
- Quels droits, variantes ou indicateurs réels empêchent une tâche de se terminer correctement ?
Exemple illustratif de mission
- Situation
- Un formulaire de demande fonctionne sur ordinateur mais perd des informations et confirme mal l’envoi sur mobile.
- Travail
- Tester le parcours complet avec clavier, zoom et réseau lent ; rapprocher erreurs techniques, messages vus par les personnes et événements de mesure.
- Livrable
- Une liste priorisée de corrections, des critères d’acceptation observables et un contrôle de non-régression après livraison.
Exemples de critères à convenir au cadrage
- La tâche essentielle aboutit sur mobile, au clavier et après une erreur.
- Une dépendance indisponible ne laisse pas un état trompeur.
- Les scripts retirés ne réapparaissent pas par un chargement secondaire.
Méthodes publiques associées
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Nommer des classes de faiblesses logicielles et matérielles. |
Une CWE décrit une faiblesse pouvant contribuer à l’introduction de vulnérabilités. Elle ne représente pas un incident particulier. | Reliez la faiblesse au mécanisme observé : entrée, traitement et contrôle manquant. Utilisez cette description pour corriger la cause et préparer des tests de régression. | La présence d’un mot-clé dans un rapport ne suffit pas à établir la bonne classification CWE. |
| W3C · WCAG 2.2 Évaluer des critères d’accessibilité du contenu web. |
WCAG 2.2 est une recommandation W3C. Les critères de réussite sont classés en niveaux A, AA et AAA. | Définissez tâches, pages et états à vérifier, puis combinez inspection, clavier, zoom et technologies d’assistance pertinentes. Conservez les étapes de reproduction des barrières. | Un scanner automatique ne démontre pas la conformité d’un parcours complet. L’évaluation doit couvrir les états interactifs et les contenus réellement utilisés. |
| Google · Core Web Vitals Distinguer vitesse d’affichage, réactivité et stabilité visuelle. |
Les repères « bon » sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1, au 75e percentile, avec segmentation mobile et ordinateur. | Séparez mesures de terrain et tests de laboratoire. Relevez période, URL, appareil, population et taille d’échantillon avant de comparer une évolution. | Ces seuils ne sont pas des résultats mesurés de ce site. Un bon score de laboratoire ne prouve pas à lui seul l’expérience des visiteurs. |
Identités : facteurs, sessions et récupération
Intégrer la connexion au cycle de vie du compte
Le parcours d’authentification doit rester cohérent avec les permissions, les sessions et le support. Une API de biométrie ou un bouton passkey ne démontre pas la sécurité de l’ensemble.
- Contrôler côté serveur les propriétés attendues du protocole.
- Tester expiration, déconnexion et ajout d’un authentificateur.
- Vérifier le secours au clavier et sans biométrie.
Ouvrir le comparatif des facteurs et de la récupération →
Sources consultées le · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
ETag, cache HTTP et modifications concurrentes
Performance web : revalider sans exposer une réponse personnalisée
Un gain de transfert par 304 ne prouve pas qu’une réponse peut être partagée entre utilisateurs. La recette doit vérifier les droits et la sélection des variantes.
- Distinguer cache privé du navigateur et cache partagé du CDN.
- Vérifier ETag, Vary et Cache-Control pour deux comptes de test autorisés différents.
- Conserver les en-têtes attendus du 304 et un cas de refus d’accès ; ne pas réutiliser une réponse sur le seul ETag.
Explorer les comparaisons et le simulateur ETag →
Références relues le · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
Retry-After : attente, budget et décision de reprise
Une attente utile doit préserver l’intention de l’utilisateur
Un écran qui attend indéfiniment ou recrée une opération après une erreur peut masquer une panne et provoquer des doublons.
- Prévoir une durée totale, un état d’attente lisible et un chemin de reprise conservant la saisie utile.
- Ne pas annoncer un échec métier à partir d’un simple délai réseau dépassé.
- Tester les clics répétés et le retour après interruption avec une identité d’opération stable lorsque le contrat le prévoit.
Explorer Retry-After et le modèle de reprise →
Références relues le · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS
Signature et provenance du build
Relier les pièces de livraison aux octets déployés
Une SBOM, un VEX et une provenance peuvent accompagner une même livraison tout en portant des informations différentes. Pour exploiter ces pièces, conserver leur liaison au paquet exact et les attentes utilisées pour accepter son origine.
- Comparer le digest de l’artefact au sujet attesté ; garder la référence entre réception, promotion et déploiement.
- Vérifier identité autorisée, builder, dépôt et paramètres plutôt que conclure sur la seule présence d’une signature.
- Conserver les contrôles de comportement et de récupération : un paquet authentique peut encore régresser.
Lire la fiche de provenance avant déploiement →
Sources vérifiées le · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures
Webhooks : signatures et rejeu
Concevoir une entrée webhook traçable et récupérable
Une intégration web doit préciser ce que signifie son 2xx : admission durable, traitement terminé ou autre contrat explicite. La file, la concurrence et la reprise doivent rester observables après une panne.
- Préserver le corps brut avant les transformations du framework.
- Relier chaque effet local à une opération et une contrainte d’unicité.
- Exercer les échecs de file et la perte de réponse avant mise en production.
Voir les signatures, les empreintes et les dix cas webhooks →
Sources vérifiées le · Stripe · Webhooks · Stripe · Manage webhook endpoints · GitHub · Validating webhook deliveries · GitHub · Best practices for using webhooks · GitHub · Handling failed webhook deliveries
Fichiers : quarantaine et retrait
Un contenu récupéré reste à contrôler avant diffusion
Téléverser un document ou le récupérer par URL ne décide pas de sa mise à disposition. L’original et les dérivés doivent conserver leur version, leurs contrôles et leur état d’accès jusqu’à chaque lecture.
- Isoler les fichiers reçus avant les traitements et la diffusion.
- Refuser un retour de traitement visant une ancienne version ou décision.
- Vérifier les droits et le retrait sur les aperçus comme sur l’original.
Voir les trois parcours et les retours tardifs →
Sources relues le · OWASP · File Upload Cheat Sheet · OWASP · Authorization Cheat Sheet · WHATWG · HTML input accept · PostgreSQL 18 · Transaction isolation
Pagination : cohérence et reprise
Le point de reprise suit le lot effectivement conservé
Une relance doit savoir quels objets ont été conservés et dans quelle vue. Avancer la continuation avant la confirmation du lot peut perdre des données ; relire le lot demande une déduplication et une politique d’effets externes.
- Tester une panne entre conservation du lot et point de contrôle.
- Ne pas annoncer la fin sur la seule taille de page.
- Revérifier les permissions et la validité de la référence à chaque reprise.
Comparer les lectures et les reprises calculées →
Sources relues le · Google · AIP-158 Pagination · PostgreSQL 18 · LIMIT and OFFSET · PostgreSQL 18 · Row constructor comparison · PostgreSQL 18 · Transaction isolation · OWASP · API1:2023 Broken Object Level Authorization
Explorer le catalogue KEV de CISA
Intégrer le suivi aux opérations de maintenance
L’ajout d’une notice constitue une entrée de travail, pas une fermeture automatique. Relier le suivi des vulnérabilités à l’inventaire, à une fenêtre de changement et à une vérification du service après intervention.
- Nommer le responsable de la décision et du changement.
- Distinguer correctif disponible, correctif déployé et contrôle réussi.
- Préserver la source, le résultat observé et les limites restantes.
Consulter le catalogue et sa méthode →
CISA KEV · 2026.10.21 · Consultation documentaire : 2026-10-22
Repères IANA et lecture DNSSEC
Distinguer résolution, cache et réponse web
Une indisponibilité peut apparaître avant toute réponse HTTP. La résolution DNS, sa validation et les caches doivent être examinés séparément du serveur web.
- Noter l’étape où la requête échoue et le résolveur concerné.
- Un TTL reçu et une expiration RRSIG sont deux contraintes différentes.
- La disparition d’une erreur sur un poste ne prouve pas une reprise pour tous les visiteurs.
Lire les registres et essayer le modèle de cache →
IETF · RFC 4033 · §3–5 · 2026-10-23
Formulaires : critères, erreurs et contraste
Examiner les états, pas seulement la page initiale
Un formulaire peut sembler clair avant saisie et devenir difficile à utiliser après une erreur. Une revue utile garde le contexte de la tâche et relie chaque constat à une version et à un état.
- Tester attente, erreur, correction et confirmation.
- Séparer calcul de contraste, navigation clavier et restitution des messages.
- Conserver les étapes permettant de reproduire la barrière.
Ouvrir la grille WCAG et le calculateur de contraste →
W3C WAI · Forms Tutorial · User Notifications · Practical guidance · consulted 2026-10-23
Extensions : permissions et accès
Ajouter le navigateur au périmètre d’exposition
Un site peut être correctement durci tout en étant consulté depuis un profil doté d’extensions très autorisées. La revue doit conserver la frontière entre sécurité du site, capacités du navigateur et choix du poste administré.
- Inventorier les extensions du profil de test avec leur version et leur propriétaire.
- Expliquer pourquoi un accès à un hôte est nécessaire et contrôler les permissions optionnelles effectivement accordées.
- Tester limitation d’accès et retrait ; un lecteur statique de manifeste ne remplace pas l’observation du code et des flux.
Consulter le répertoire et les exemples de manifestes →
Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23
Codes syslog et preuves de collecte
Une normalisation doit conserver le sens des événements
Dans une API distribuée, un entier PRI mélange deux codes. Une conversion opaque peut perdre la famille du message ou inverser la gravité. Testez la chaîne de collecte avec des événements identifiés avant d’en déduire une fiabilité opérationnelle.
- Conserver facility, severity et valeur brute dans des champs distincts.
- Distinguer heure source, heure de réception et disponibilité dans la recherche.
- Rendre visibles les rejets, troncatures, pertes et règles de conversion.
Lire les codes syslog et tester le calcul PRI →
IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23
ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23
Erreurs API : types, statuts et preuves
Traiter une erreur sans analyser sa phrase
Un client API peut recevoir un titre traduit, un membre manquant ou une extension qu’il ne connaît pas. Préservez une décision fondée sur le type documenté et le statut HTTP, puis associez une action sûre au contexte.
- Comparer statut reçu et status du JSON sans remplacer silencieusement l’un par l’autre.
- Tester un type absent, une chaîne à la place du nombre status et une extension inconnue.
- Séparer message destiné à la personne, code métier et référence d’occurrence.
Explorer les types de problèmes et les huit réponses fictives →
IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5
CSP : directives, replis et parcours
Une CSP se déploie avec des preuves de parcours
Une politique en observation et une politique appliquée n’ont pas le même effet. Les transformations du serveur, du CDN et du proxy peuvent aussi produire plusieurs politiques reçues.
- Conserver les politiques brutes, leur mode, leur livraison et la version de la page.
- Tester connexion, formulaire, paiement et récupération selon le périmètre.
- Associer rapports, défauts et critères d’arrêt avant la décision d’application.
Lire les replis CSP et explorer les huit scénarios →
W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1
GraphQL : erreurs, listes et données partielles
Livrer une interface GraphQL qui explique les données manquantes
Associer les types Non-Null aux actions réellement indispensables et définir un affichage compréhensible de la fiche partielle.
- Comparer data absente, data partielle et data: null.
- Conserver le chemin original, même si un parent devient null.
- Tester les droits, les quotas et les états d’interface séparément.
Explorer les réponses GraphQL et leur nullabilité →
GraphQL Specification · September 2025 · Published edition · September 2025
Core Web Vitals : seuils et données terrain
Concevoir une performance qui sert le parcours
LCP, INP et CLS répondent à des questions différentes. Relier chaque correction à un élément et à une action réels.
- Comparer le même appareil, le même périmètre et des périodes documentées.
- Ne pas transformer une donnée absente en zéro.
- Vérifier les fonctions et l’accessibilité après le correctif.
Lire les seuils et essayer le lecteur p75 →
Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23
Identité produit : GTIN et variantes
Fiches produit : relier groupe, variante et offre
La même référence doit rester retrouvable après un lien partagé, un changement d’option et un passage au panier.
- Conserver les zéros et les valeurs brutes utiles à la recette.
- Tester l’URL qui présélectionne chaque variante.
- Comparer identité, prix et disponibilité dans la fiche et le panier.
Explorer les identifiants et contrôler une clé GTIN →
GS1 · 2D Barcodes at Retail POS Implementation Guideline · Release 1.1.0 · ratified December 2025 · §4.3 / Table 4-2
Google Search Central · Product variant structured data · Updated 2026-09-08 · consulted 2026-10-23
Répartition A/B : données et SRM
Tests A/B : contrôler le ratio avant la décision
Un déséquilibre inexpliqué peut venir de l’affectation, du parcours exécuté, des journaux ou des filtres d’analyse. Le SRM aide à enquêter ; il ne mesure pas l’amélioration du produit.
- Vérifier le ratio prévu et la stabilité de l’unité avant toute comparaison de conversion.
- Ne pas interpréter une absence de signal comme une preuve de validité globale.
- Documenter séparément le contrôle de qualité, l’effet mesuré et la décision de déploiement.
Explorer le contrôle de répartition et ses limites →
Microsoft Research · Diagnosing Sample Ratio Mismatch · Published 2020-09-14 · consulted 2026-10-23
NIST/SEMATECH · Binomial distribution · e-Handbook §1.3.6.6.18 · consulted 2026-10-23
API : dépréciation et retrait
Préparer le retrait au-delà du numéro de version
Une version publiée ne dit pas quand les consommateurs doivent migrer. Relier les annonces de dépréciation, les dates de retrait et les tests des clients existants.
- Distinguer Deprecation, Sunset et les liens vers les politiques.
- Vérifier que Sunset n’est pas antérieur à Deprecation lorsque les deux dates sont fournies.
- Mesurer les consommateurs restants et valider le remplacement avant une bascule.
Comparer les annonces de dépréciation et de retrait →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23
Cardinalité des jointures, NULL et agrégats
Recetter les jointures qui alimentent la décision
Une API ou un pipeline disponible peut livrer un tableau de bord faux si les relations entre sources ne respectent pas leur grain. La recette doit établir quelles lignes sont attendues, répétées ou absentes avant de valider les indicateurs affichés.
- Conserver une somme indépendante et les versions des deux sources.
- Ajouter une source droite vide et une clé répétée à la recette.
- Vérifier les valeurs NULL et les lignes exclues séparément.
Examiner les paires et les agrégats dans l’atelier →
PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23
PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23
PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23
Précision des montants API et unités exactes
Séparer conversion exacte et confirmation du paiement
Une interface peut afficher le bon prix tout en préparant un entier incorrect pour le prestataire. La recette doit rapprocher le montant serveur avec le contrat de l’opération, puis vérifier l’état confirmé sans confondre le calcul avec un paiement abouti.
- Tester une monnaie à zéro, deux et trois décimales.
- Inclure une exception où le pas ne se déduit pas des décimales.
- Conserver une valeur de référence exacte avant le formatage localisé.
Vérifier une unité dans l’atelier →
Adyen · Currency codes and minor units · Provider documentation · reviewed 2026-10-23
Stripe · Supported currencies and special cases · Provider documentation · reviewed 2026-10-23
FAQ
Questions fréquentes
Les réponses utiles pour qualifier le besoin avant un premier échange.
L’audit couvre-t-il à la fois UX, performance et sécurité ?
Oui. Ces dimensions sont analysées ensemble car un parcours rapide mais confus, ou clair mais vulnérable, ne produit pas un service web durable.
Pouvez-vous intervenir sur un site existant ?
Oui. La mission peut commencer par un audit ciblé, corriger les points prioritaires, préparer une refonte ou mettre en place une maintenance continue selon l’état du socle existant.
Que vérifier après la correction d’un formulaire ?
Repartir du début : saisie, erreur provoquée, correction puis confirmation. Vérifier conservation des valeurs, messages, déplacement du focus et résultat côté serveur, sur mobile, au clavier et avec zoom. Le succès d’un composant isolé ne prouve pas que le parcours complet fonctionne ni que tout le site est accessible.
Concevoir des formulaires accessibles et des erreurs réparables
Écosystème numérique
Prolonger l’analyse avec des ressources spécialisées.
Française du Numérique
Création web, SEO et contenus
francaise-du-numerique.fr
FRExplorer
French Digital Society
Métiers et expertises numériques
french-digital-society.com
FRExplorer
Internet Intelligence Service
OSINT, veille et due diligence
internet-intelligence-service.com
FRExplorer
CFSN
Support numérique pour TPE et PME
cfsn.fr
FRExplorer
World Affiliate Guide
Affiliation et marketing à la performance
world-affiliate-guide.com
FRExplorer
World Social Networks
Réseaux sociaux, usages et vie privée
world-social-networks.com
FRExplorer
World Web Certified
Annuaire web éditorial et guides
worldwebcertified.com
FRExplorer