Symfony Profiler

[
  "headers" => [
    "Authorization" => "Basic MDAwNTEwNDA0YzhjNGY0ZDkxYjZhMDVlY2RkOWEyYjQ6ZXJ5b25pYV90ZXN0"
    "Accept" => "application/json"
  ]
  "extra" => [
    "allow_redirects" => true
  ]
  "query" => [
    "language" => "fra+eng"
  ]
  "body" => [
    "document" => stream resource @47
      timed_out: false
      blocked: true
      eof: true
      wrapper_type: "plainfile"
      stream_type: "STDIO"
      mode: "r"
      unread_bytes: 0
      seekable: true
      uri: "/tmp/phpgd0028sijj9f4Asw2tr"
      options: []
    }
    "reference" => "1769704856.03973603"
  ]
  "timeout" => 30
]

[
  "info" => [
    "header_size" => 702
    "request_size" => 86917
    "total_time" => 2.33580399999999999
    "namelookup_time" => 0.0177180000000000011
    "connect_time" => 0.0187890000000000001
    "pretransfer_time" => 0.0419360000000000011
    "size_upload" => 86587.0
    "size_download" => 29839.0
    "speed_download" => 12774.0
    "speed_upload" => 37069.0
    "starttransfer_time" => 2.30139199999999988
    "primary_ip" => "212.114.19.93"
    "primary_port" => 443
    "local_ip" => "172.19.3.30"
    "local_port" => 50544
    "http_version" => 3
    "protocol" => 2
    "scheme" => "https"
    "appconnect_time_us" => 41618
    "connect_time_us" => 18789
    "namelookup_time_us" => 17718
    "pretransfer_time_us" => 41936
    "starttransfer_time_us" => 2301392
    "posttransfer_time_us" => 42701
    "total_time_us" => 2335804
    "effective_method" => "POST"
    "capath" => "/etc/ssl/certs"
    "cainfo" => "/etc/ssl/certs/ca-certificates.crt"
    "start_time" => 1769704856.07336092
    "original_url" => "https://local-ia.eryon.eu/api/ocr?language=fra%2Beng"
    "pause_handler" => Closure(float $duration) {#1587
      class: "Symfony\Component\HttpClient\Response\CurlResponse"
      use: {
        $ch: CurlHandle {#1557 …}
        $multi: Symfony\Component\HttpClient\Internal\CurlClientState {#78 …}
        $execCounter: -9223372036854775808
      }
    }
    "debug" => """
      * Host local-ia.eryon.eu:443 was resolved.\n
      * IPv6: (none)\n
      * IPv4: 212.114.19.93\n
      *   Trying 212.114.19.93:443...\n
      * ALPN: curl offers h2,http/1.1\n
      *  CAfile: /etc/ssl/certs/ca-certificates.crt\n
      *  CApath: /etc/ssl/certs\n
      * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey\n
      * ALPN: server accepted h2\n
      * Server certificate:\n
      *  subject: CN=local-ia.eryon.eu\n
      *  start date: Jan 16 14:14:18 2026 GMT\n
      *  expire date: Apr 16 14:14:17 2026 GMT\n
      *  subjectAltName: host "local-ia.eryon.eu" matched cert's "local-ia.eryon.eu"\n
      *  issuer: C=US; O=Let's Encrypt; CN=E8\n
      *  SSL certificate verify ok.\n
      *   Certificate level 0: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384\n
      *   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption\n
      *   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption\n
      * Connected to local-ia.eryon.eu (212.114.19.93) port 443\n
      * using HTTP/2\n
      * [HTTP/2] [1] OPENED stream for https://local-ia.eryon.eu/api/ocr?language=fra%2Beng\n
      * [HTTP/2] [1] [:method: POST]\n
      * [HTTP/2] [1] [:scheme: https]\n
      * [HTTP/2] [1] [:authority: local-ia.eryon.eu]\n
      * [HTTP/2] [1] [:path: /api/ocr?language=fra%2Beng]\n
      * [HTTP/2] [1] [authorization: Basic MDAwNTEwNDA0YzhjNGY0ZDkxYjZhMDVlY2RkOWEyYjQ6ZXJ5b25pYV90ZXN0]\n
      * [HTTP/2] [1] [accept: application/json]\n
      * [HTTP/2] [1] [content-type: multipart/form-data; boundary=gcwStqfVD7KgfVz4w7AArA]\n
      * [HTTP/2] [1] [content-length: 86587]\n
      * [HTTP/2] [1] [user-agent: Symfony HttpClient (Curl)]\n
      * [HTTP/2] [1] [accept-encoding: gzip]\n
      > POST /api/ocr?language=fra%2Beng HTTP/2\r\n
      Host: local-ia.eryon.eu\r\n
      Authorization: Basic MDAwNTEwNDA0YzhjNGY0ZDkxYjZhMDVlY2RkOWEyYjQ6ZXJ5b25pYV90ZXN0\r\n
      Accept: application/json\r\n
      Content-Type: multipart/form-data; boundary=gcwStqfVD7KgfVz4w7AArA\r\n
      Content-Length: 86587\r\n
      User-Agent: Symfony HttpClient (Curl)\r\n
      Accept-Encoding: gzip\r\n
      \r\n
      * upload completely sent off: 86587 bytes\n
      < HTTP/2 200 \r\n
      < server: openresty\r\n
      < date: Thu, 29 Jan 2026 16:40:58 GMT\r\n
      < content-type: application/json\r\n
      < x-powered-by: PHP/8.4.17\r\n
      < cache-control: max-age=0, must-revalidate, private\r\n
      < x-debug-token: 9cda94\r\n
      < x-debug-token-link: https://local-ia.eryon.eu/_profiler/9cda94\r\n
      < x-robots-tag: noindex\r\n
      < expires: Thu, 29 Jan 2026 16:40:58 GMT\r\n
      * Added cookie api_auth_profile_token="9cda94" for domain local-ia.eryon.eu, path /, expire 0\n
      < set-cookie: api_auth_profile_token=9cda94; path=/; httponly; samesite=lax\r\n
      * Added cookie api_deauth_profile_token="deleted" for domain local-ia.eryon.eu, path /, expire 1\n
      < set-cookie: api_deauth_profile_token=deleted; expires=Wed, 29 Jan 2025 16:40:57 GMT; Max-Age=0; path=/; httponly\r\n
      * Added cookie PHPSESSID="9e858cf0a1d5bc3d1aa590358638e312" for domain local-ia.eryon.eu, path /, expire 0\n
      < set-cookie: PHPSESSID=9e858cf0a1d5bc3d1aa590358638e312; path=/; secure; httponly; samesite=lax\r\n
      < strict-transport-security: max-age=63072000; preload\r\n
      < x-served-by: local-ia.eryon.eu\r\n
      < \r\n
      """
  ]
  "url" => "https://local-ia.eryon.eu/api/ocr?language=fra%2Beng"
  "response_headers" => [
    "HTTP/2 200 "
    "server: openresty"
    "date: Thu, 29 Jan 2026 16:40:58 GMT"
    "content-type: application/json"
    "x-powered-by: PHP/8.4.17"
    "cache-control: max-age=0, must-revalidate, private"
    "x-debug-token: 9cda94"
    "x-debug-token-link: https://local-ia.eryon.eu/_profiler/9cda94"
    "x-robots-tag: noindex"
    "expires: Thu, 29 Jan 2026 16:40:58 GMT"
    "set-cookie: api_auth_profile_token=9cda94; path=/; httponly; samesite=lax"
    "set-cookie: api_deauth_profile_token=deleted; expires=Wed, 29 Jan 2025 16:40:57 GMT; Max-Age=0; path=/; httponly"
    "set-cookie: PHPSESSID=9e858cf0a1d5bc3d1aa590358638e312; path=/; secure; httponly; samesite=lax"
    "strict-transport-security: max-age=63072000; preload"
    "x-served-by: local-ia.eryon.eu"
  ]
  "response_json" => [
    "success" => true
    "data" => [
      "error" => null
      "errorDetails" => null
      "status" => 200
      "markdown" => """
        INTERFACES PERSONNE-MACHINE\n
        \n
        UTILISATEURS ET CONTEXTE\n
        \n
        # Analyse des utilisateurs et du contexte\n
        \n
        Lors de la conception d'une interface il faut nécessairement se poser la question de qui sont ou seront les utilisateurs du système. Si le noyau fonctionnel d'un système doit en général être indépendant des utilisateurs, son interface doit au contraire être construite en fonction des utilisateurs et de leurs caractéristiques.\n
        \n
        La connaissance des utilisateurs est un moyen d'éviter des erreurs grossières dans une interface. Parmi les erreurs typiques dues à une méconnaissance des utilisateurs on peut citer:\n
        \n
        - s'adresser aux utilisateurs avec un vocabulaire qu'ils ne comprennent pas (p.ex. trop spécialisé)\n
        - oublier que certains utilisateurs distinguent mal les couleurs (10\% des hommes sont daltoniens)\n
        - utiliser des symboles ou des couleurs qui n'ont pas de sens ou pas le sens voulu dans la culture de l'utilisateur\n
        - frustrer les utilisateurs experts en les obligeant à répéter des séquences d'opérations prévues pour les débutants\n
        - etc.\n
        \n
        # Le contexte d'utilisation\n
        \n
        De plus, les utilisateurs évoluent dans un contexte particulier, dont il faut tenir compte. Acheter un billet de train par internet, confortablement installé chez soi est bien différent de l'acheter sur une borne interactive dans une gare bruyante 30 secondes avant l'arrivée du train. Celles et ceux qui ont essayé d'emmener leur ordinateur portable à la plage savent bien que la forte luminosité rend un écran LCD usuel quasi inutilisable dans ce contexte (sans parler du sable dans le clavier).\n
        \n
        Contexte physique. Il s'agit de toutes les conditions d'utilisation de l'interface que l'on peut décrire par des grandeurs physiques: température, ambiance sonore, vibrations, luminosité, atmosphère, position, objets de l'espace environnant, etc. Le contexte physique détermine souvent le type de technologie utilisable ou non. Les caractéristiques physiques du contexte peuvent forcer à choisir une technologie plutôt qu'une autre : un mécanicien travaillant dans un moteur d'avion ne peut pas accéder à une base de données des pièces via un PC standard. Le contexte peut influer sur le design de l'interface mais aussi sur la technologie à employer\n
        \n
        Contexte organisationnel et de travail. Si le système est utilisé à l'intérieur d'une organisation, il va servir à effectuer des tâches qui s'inscrivent dans des flux de travail (explicites ou implicites). La connaissance de ces flux peut être nécessaire pour bien comprendre les besoins et les contraintes que le système devra satisfaire. Chaque organisation possède également ses normes, p.ex. la nomenclature à employer, qu'il faudra respecter.\n
        \n
        Le contexte organisationnel et en particulier l'ensemble des activités dans lesquelles l'utilisateur est engagé à un instant donné peuvent avoir une profonde influence sur l'état psychologique de l'utilisateur. Il peut être stressé par l'importance des décisions qu'il doit prendre ou bien surchargé cognitivement par un ensemble d'événements qui\n
        INTERFACES PERSONNE-MACHINE\n
        UTILISATEURS ET CONTEXTE\n
        \n
        surviennent simultanément, etc. Par exemple, un automobiliste est principalement occupé à conduire, il ne peut quitter la route des yeux que pendant de très courtes périodes. Tout équipement, navigateur GPS, radio, contrôle du véhicule, doit avoir une interface adaptée à cette situation, par exemple : interface auditive, affichage en gros caractères, commandes tactiles proches du volant, etc. De même, l'interface de contrôle des vannes d'une usine chimique doit tenir compte du fait que certaines opérations sont critiques et que l'utilisateur sera stressé lorsqu'il les exécutera.\n
        \n
        **Contexte social.** Tout utilisateur se trouve plongé dans un contexte social qui possède ses normes, ses codes, ses relations interpersonnelles. L'interface doit s'y adapter. Si le noir est la couleur du deuil dans les sociétés européennes, ce n'est pas le cas ailleurs, le choix des couleurs dans une interface devra tenir compte de ce genre de code pour éviter de choquer l'utilisateur ou de l'induire en erreur. De même, les critères esthétiques vont varier d'une culture à l'autre.\n
        \n
        En général, le contexte dans lequel une interface sera utilisée est déterminé à l'avance et considéré comme fixe. Cependant il se peut, et c'est souvent le cas, que l'introduction d'un système informatique ait une influence sur le contexte, en particulier sur le contexte organisationnel. Par exemple, l'introduction de panneaux d'information interactifs peut modifier le comportement des usagers des transports publics.\n
        \n
        ## Caractérisation des utilisateurs\n
        \n
        On peut effectuer l'analyse des utilisateurs selon différents axes, dont l'importance variera en fonction du système à réaliser.\n
        \n
        ## Caractérisation psycho-cognitive\n
        \n
        Dans ce cas on s'intéresse aux différences cognitives entre utilisateurs. Un utilisateur sera caractérisé, entre autre, par son niveau de connaissance selon plusieurs axes :\n
        \n
        - système: novice, moyen, avancé, expert\n
        - domaine d'application: grand public, connaissances de base, ..., professionnel\n
        - informatiques: il ne s'agit pas de connaissances de l'informatique en tant que science et technique mais plutôt de sa connaissance de concepts fréquemment utilisés : copier/coller, défaire une action, réagir en cas d'erreur, notion de document, de fichier, de base de donnée, de réseau, etc. Certains auteurs préfèrent parler de connaissance des médias à interactions complexes\n
        \n
        Si le système s'adresse à des utilisateurs de différents niveaux de connaissances il faudra très probablement prévoir différentes manières d'interagir. Par exemple, une interaction guidée pour les débutants, des raccourcis clavier pour les utilisateurs fréquents, etc.\n
        \n
        Si le système d'adresse à des professionnels du domaine il faudra employer une terminologique spécialisée et proposer des actions correspondant à leurs habitudes et standards. À l'inverse, une interface pour le grand public devra présenter les choses en des termes simples, avec des métaphores, etc.\n
        \n
        ## Caractérisation par groupes socio-démographiques\n
        \n
        Cette caractérisation dépend du contexte social et du contexte organisationnel du système, elle doit expliciter, en particulier, les points suivants :\n
        \n
        - age: enfant, adulte, personne âgée\n
        - genre: homme, femme\n
        - activité: travailleur manuel, travailleur intellectuel\n
        - langue: langue maternelle, langues maîtrisées\n
        \n
        © Uni. Genève - G. Falquet, J. Guyot, P. Roth\n
        INTERFACES PERSONNE-MACHINE\n
        UTILISATEURS ET CONTEXTE\n
        \n
        ## Caractérisation physique\n
        \n
        On s'intéressera en particulier à\n
        \n
        - l'age (enfant, adulte)\n
        - la taille\n
        - chaque type de handicap ou limitation : visuel, auditif, moteur, cérébral, ...\n
        \n
        ## Caractérisation par rôle : les acteurs dans UML\n
        \n
        Cette caractérisation est fortement liée au contexte organisationnel. Dans les cas d'utilisation d'UML on propose de définir des "acteurs". Chaque acteur représente un rôle joué par un utilisateur. Une même personne pourra donc apparaître comme différents acteurs. Par exemple, dans une petite entreprise les acteurs "vendeur", "directeur" et "comptable" pourront correspondre à la même personne. Inversement, plusieurs personnes peuvent apparaître comme le même acteur. Par exemple, l'acteur "client" d'un magasin en ligne correspondra à des milliers de personnes différentes.\n
        \n
        On peut différencier plus finement les acteurs en les classant selon une taxonomie. Par exemple, l'acteur "client" pourra posséder deux sous-acteurs: "client occasionnel" et "client régulier".\n
        \n
        Dans UML la définition des acteurs sert essentiellement à déterminer à qui sont destinés les différents services (cas d'utilisation) fournis par le système.\n
        \n
        ## Techniques de récolte de l'information\n
        \n
        On peut appliquer différentes techniques pour récolter de l'information sur les utilisateurs : les interviews, l'observation ou encore les focus groups.. Le but de cette récolte est non seulement de déterminer qui seront les utilisateurs mais aussi de cerner leurs besoins, leurs attentes, leurs craintes, etc. Cette information servira non seulement à déterminer qui sont les utilisateurs mais également à centrer l'analyse des tâches (voir le chapitre consacré à ce sujet) sur les utilisateurs.\n
        \n
        La technique des interviews comprend les étapes suivantes:\n
        \n
        1. sélectionner les participants\n
        2. décider de ce que les interviews doivent nous apprendre\n
        3. écrire le protocole (script) de l'interview\n
        4. passage de l'interview avec les participants\n
        5. analyse des résultats\n
        \n
        Les interviews devront toucher différentes catégories de personnes :\n
        \n
        - les preneurs de décisions, pour obtenir une vision du système, définir le budget, le temps disponible pour le développement\n
        - les spécialistes du domaine, pour comprendre comment fonctionne le domaine, le métier\n
        - les responsables organisationnels (si le système doit fonctionner dans une organisation), pour bien comprendre le contexte de travail global\n
        - les vendeurs, qui seront chargés de vendre le système, s'il s'agit d'un produit, ou de la promouvoir dans une organisation\n
        - et bien sûr les utilisateurs finaux, qui en général ont une vision de leur activité bien différente de celle des organisateurs ou des "théoriciens" du domaine\n
        \n
        Lorsqu'on prend contact avec des personnes pour une éventuelle interview, il est toujours intéressant de noter\n
        \n
        © Uni. Genève - G. Falquet, J. Guyot, P. Roth\n
        INTERFACES PERSONNE-MACHINE\n
        UTILISATEURS ET CONTEXTE\n
        \n
        - qui est d'accord et qui ne l'est pas\n
        - si ces gens sont-ils intéressés et sinon pourquoi\n
        \n
        L'interview doit essayer de dégager quels seront les utilisateurs types du système, dans quel environnement il vont l'utiliser et quels sont leurs besoins. Il faut rendre le participant aussi actif que possible lors de l'interview.\n
        \n
        On peut compléter les interviews par un questionnaire (en ligne) qui permet d'atteindre un plus grand nombre de personnes. Le questionnaire peut faire émerger des tendances générales, ce qui est impossible avec un petit nombre d'interviews.\n
        \n
        ## Observation\n
        \n
        La collecte de données par observation consiste à se rendre sur le lieu de travail de l'utilisateur pour comprendre son contexte de travail, son environnement social, les technologies utilisées, etc. Il y a de nombreuses manières de réaliser l'observation. On peut rester auprès de l'utilisateur et lui poser de temps à autre des questions; ou bien filmer l'utilisateur pendant un certain temps puis regarder et commenter le film avec l'utilisateur ou avec un spécialiste du domaine; ou encore prendre la place de l'utilisateur et faire le travail soi-même.\n
        \n
        La technique du focus group consiste à réunir une petite nombre d'utilisateurs potentiels (entre 6 et 12) et à engager une discussion informelle avec eux via un modérateur. Un modérateur veille à faire participer tout le monde, à recentrer la discussion sur le système. Le focus groupe sert à faire émerger les besoins, les désirs et de nouvelles idées.\n
        \n
        ## Créer un ensemble de personnages\n
        \n
        La création de personnages est une manière de représenter l'information collectée auprès des utilisateurs. Sur la base de ces informations on détermine un ou plusieurs profils d'utilisateurs types crédibles. L'idée de base est d'éviter de faire des moyennes mais au contraire de représenter la diversité des utilisateurs. On voit bien qu'il serait vain d'essayer de créer un personnage qui représenterait à la fois un jeune étudiant et un retraité.\n
        \n
        On définit précisément chaque personnage en donnant son âge, son sexe, une brève biographie, une photo. Par exemple\n
        \n
        ## exemple\n
        \n
        Pour le système de réservation en ligne d'une compagnie aérienne on définit deux personnages.\n
        \n
        **Marie Duparc** : 31 ans, voyage en classe affaires. Bilingue français-anglais, elle voyage régulièrement pour ses affaires. Elle aime bien regarder la section shopping et loisirs du site.\n
        \n
        **Georges Rémi** : 73 ans, voyage en classe économique. Commence à être âgé mais toujours très actif. Il est un peu gêné par un début d'arthrite dans ses doigts. Il n'a pas d'ordinateur à la maison et ne s'est jamais servi d'un ordinateur au travail.\n
        \n
        L'étape suivante consiste à associer un ou plusieurs scénarios d'utilisation à chaque personnage, comme nous le verrons dans le chapitre suivant.\n
        \n
        © Uni. Genève - G. Falquet, J. Guyot, P. Roth
        """
      "images" => []
      "pages" => [
        [
          "index" => 0
          "markdown" => """
            INTERFACES PERSONNE-MACHINE\n
            \n
            UTILISATEURS ET CONTEXTE\n
            \n
            # Analyse des utilisateurs et du contexte\n
            \n
            Lors de la conception d'une interface il faut nécessairement se poser la question de qui sont ou seront les utilisateurs du système. Si le noyau fonctionnel d'un système doit en général être indépendant des utilisateurs, son interface doit au contraire être construite en fonction des utilisateurs et de leurs caractéristiques.\n
            \n
            La connaissance des utilisateurs est un moyen d'éviter des erreurs grossières dans une interface. Parmi les erreurs typiques dues à une méconnaissance des utilisateurs on peut citer:\n
            \n
            - s'adresser aux utilisateurs avec un vocabulaire qu'ils ne comprennent pas (p.ex. trop spécialisé)\n
            - oublier que certains utilisateurs distinguent mal les couleurs (10\% des hommes sont daltoniens)\n
            - utiliser des symboles ou des couleurs qui n'ont pas de sens ou pas le sens voulu dans la culture de l'utilisateur\n
            - frustrer les utilisateurs experts en les obligeant à répéter des séquences d'opérations prévues pour les débutants\n
            - etc.\n
            \n
            # Le contexte d'utilisation\n
            \n
            De plus, les utilisateurs évoluent dans un contexte particulier, dont il faut tenir compte. Acheter un billet de train par internet, confortablement installé chez soi est bien différent de l'acheter sur une borne interactive dans une gare bruyante 30 secondes avant l'arrivée du train. Celles et ceux qui ont essayé d'emmener leur ordinateur portable à la plage savent bien que la forte luminosité rend un écran LCD usuel quasi inutilisable dans ce contexte (sans parler du sable dans le clavier).\n
            \n
            Contexte physique. Il s'agit de toutes les conditions d'utilisation de l'interface que l'on peut décrire par des grandeurs physiques: température, ambiance sonore, vibrations, luminosité, atmosphère, position, objets de l'espace environnant, etc. Le contexte physique détermine souvent le type de technologie utilisable ou non. Les caractéristiques physiques du contexte peuvent forcer à choisir une technologie plutôt qu'une autre : un mécanicien travaillant dans un moteur d'avion ne peut pas accéder à une base de données des pièces via un PC standard. Le contexte peut influer sur le design de l'interface mais aussi sur la technologie à employer\n
            \n
            Contexte organisationnel et de travail. Si le système est utilisé à l'intérieur d'une organisation, il va servir à effectuer des tâches qui s'inscrivent dans des flux de travail (explicites ou implicites). La connaissance de ces flux peut être nécessaire pour bien comprendre les besoins et les contraintes que le système devra satisfaire. Chaque organisation possède également ses normes, p.ex. la nomenclature à employer, qu'il faudra respecter.\n
            \n
            Le contexte organisationnel et en particulier l'ensemble des activités dans lesquelles l'utilisateur est engagé à un instant donné peuvent avoir une profonde influence sur l'état psychologique de l'utilisateur. Il peut être stressé par l'importance des décisions qu'il doit prendre ou bien surchargé cognitivement par un ensemble d'événements qui
            """
          "images" => []
          "tables" => []
          "hyperlinks" => []
          "header" => null
          "footer" => null
          "dimensions" => [
            "dpi" => 200
            "height" => 2339
            "width" => 1654
          ]
        ]
        [
          "index" => 1
          "markdown" => """
            INTERFACES PERSONNE-MACHINE\n
            UTILISATEURS ET CONTEXTE\n
            \n
            surviennent simultanément, etc. Par exemple, un automobiliste est principalement occupé à conduire, il ne peut quitter la route des yeux que pendant de très courtes périodes. Tout équipement, navigateur GPS, radio, contrôle du véhicule, doit avoir une interface adaptée à cette situation, par exemple : interface auditive, affichage en gros caractères, commandes tactiles proches du volant, etc. De même, l'interface de contrôle des vannes d'une usine chimique doit tenir compte du fait que certaines opérations sont critiques et que l'utilisateur sera stressé lorsqu'il les exécutera.\n
            \n
            **Contexte social.** Tout utilisateur se trouve plongé dans un contexte social qui possède ses normes, ses codes, ses relations interpersonnelles. L'interface doit s'y adapter. Si le noir est la couleur du deuil dans les sociétés européennes, ce n'est pas le cas ailleurs, le choix des couleurs dans une interface devra tenir compte de ce genre de code pour éviter de choquer l'utilisateur ou de l'induire en erreur. De même, les critères esthétiques vont varier d'une culture à l'autre.\n
            \n
            En général, le contexte dans lequel une interface sera utilisée est déterminé à l'avance et considéré comme fixe. Cependant il se peut, et c'est souvent le cas, que l'introduction d'un système informatique ait une influence sur le contexte, en particulier sur le contexte organisationnel. Par exemple, l'introduction de panneaux d'information interactifs peut modifier le comportement des usagers des transports publics.\n
            \n
            ## Caractérisation des utilisateurs\n
            \n
            On peut effectuer l'analyse des utilisateurs selon différents axes, dont l'importance variera en fonction du système à réaliser.\n
            \n
            ## Caractérisation psycho-cognitive\n
            \n
            Dans ce cas on s'intéresse aux différences cognitives entre utilisateurs. Un utilisateur sera caractérisé, entre autre, par son niveau de connaissance selon plusieurs axes :\n
            \n
            - système: novice, moyen, avancé, expert\n
            - domaine d'application: grand public, connaissances de base, ..., professionnel\n
            - informatiques: il ne s'agit pas de connaissances de l'informatique en tant que science et technique mais plutôt de sa connaissance de concepts fréquemment utilisés : copier/coller, défaire une action, réagir en cas d'erreur, notion de document, de fichier, de base de donnée, de réseau, etc. Certains auteurs préfèrent parler de connaissance des médias à interactions complexes\n
            \n
            Si le système s'adresse à des utilisateurs de différents niveaux de connaissances il faudra très probablement prévoir différentes manières d'interagir. Par exemple, une interaction guidée pour les débutants, des raccourcis clavier pour les utilisateurs fréquents, etc.\n
            \n
            Si le système d'adresse à des professionnels du domaine il faudra employer une terminologique spécialisée et proposer des actions correspondant à leurs habitudes et standards. À l'inverse, une interface pour le grand public devra présenter les choses en des termes simples, avec des métaphores, etc.\n
            \n
            ## Caractérisation par groupes socio-démographiques\n
            \n
            Cette caractérisation dépend du contexte social et du contexte organisationnel du système, elle doit expliciter, en particulier, les points suivants :\n
            \n
            - age: enfant, adulte, personne âgée\n
            - genre: homme, femme\n
            - activité: travailleur manuel, travailleur intellectuel\n
            - langue: langue maternelle, langues maîtrisées\n
            \n
            © Uni. Genève - G. Falquet, J. Guyot, P. Roth
            """
          "images" => []
          "tables" => []
          "hyperlinks" => []
          "header" => null
          "footer" => null
          "dimensions" => [
            "dpi" => 200
            "height" => 2339
            "width" => 1654
          ]
        ]
        [
          "index" => 2
          "markdown" => """
            INTERFACES PERSONNE-MACHINE\n
            UTILISATEURS ET CONTEXTE\n
            \n
            ## Caractérisation physique\n
            \n
            On s'intéressera en particulier à\n
            \n
            - l'age (enfant, adulte)\n
            - la taille\n
            - chaque type de handicap ou limitation : visuel, auditif, moteur, cérébral, ...\n
            \n
            ## Caractérisation par rôle : les acteurs dans UML\n
            \n
            Cette caractérisation est fortement liée au contexte organisationnel. Dans les cas d'utilisation d'UML on propose de définir des "acteurs". Chaque acteur représente un rôle joué par un utilisateur. Une même personne pourra donc apparaître comme différents acteurs. Par exemple, dans une petite entreprise les acteurs "vendeur", "directeur" et "comptable" pourront correspondre à la même personne. Inversement, plusieurs personnes peuvent apparaître comme le même acteur. Par exemple, l'acteur "client" d'un magasin en ligne correspondra à des milliers de personnes différentes.\n
            \n
            On peut différencier plus finement les acteurs en les classant selon une taxonomie. Par exemple, l'acteur "client" pourra posséder deux sous-acteurs: "client occasionnel" et "client régulier".\n
            \n
            Dans UML la définition des acteurs sert essentiellement à déterminer à qui sont destinés les différents services (cas d'utilisation) fournis par le système.\n
            \n
            ## Techniques de récolte de l'information\n
            \n
            On peut appliquer différentes techniques pour récolter de l'information sur les utilisateurs : les interviews, l'observation ou encore les focus groups.. Le but de cette récolte est non seulement de déterminer qui seront les utilisateurs mais aussi de cerner leurs besoins, leurs attentes, leurs craintes, etc. Cette information servira non seulement à déterminer qui sont les utilisateurs mais également à centrer l'analyse des tâches (voir le chapitre consacré à ce sujet) sur les utilisateurs.\n
            \n
            La technique des interviews comprend les étapes suivantes:\n
            \n
            1. sélectionner les participants\n
            2. décider de ce que les interviews doivent nous apprendre\n
            3. écrire le protocole (script) de l'interview\n
            4. passage de l'interview avec les participants\n
            5. analyse des résultats\n
            \n
            Les interviews devront toucher différentes catégories de personnes :\n
            \n
            - les preneurs de décisions, pour obtenir une vision du système, définir le budget, le temps disponible pour le développement\n
            - les spécialistes du domaine, pour comprendre comment fonctionne le domaine, le métier\n
            - les responsables organisationnels (si le système doit fonctionner dans une organisation), pour bien comprendre le contexte de travail global\n
            - les vendeurs, qui seront chargés de vendre le système, s'il s'agit d'un produit, ou de la promouvoir dans une organisation\n
            - et bien sûr les utilisateurs finaux, qui en général ont une vision de leur activité bien différente de celle des organisateurs ou des "théoriciens" du domaine\n
            \n
            Lorsqu'on prend contact avec des personnes pour une éventuelle interview, il est toujours intéressant de noter\n
            \n
            © Uni. Genève - G. Falquet, J. Guyot, P. Roth
            """
          "images" => []
          "tables" => []
          "hyperlinks" => []
          "header" => null
          "footer" => null
          "dimensions" => [
            "dpi" => 200
            "height" => 2339
            "width" => 1654
          ]
        ]
        [
          "index" => 3
          "markdown" => """
            INTERFACES PERSONNE-MACHINE\n
            UTILISATEURS ET CONTEXTE\n
            \n
            - qui est d'accord et qui ne l'est pas\n
            - si ces gens sont-ils intéressés et sinon pourquoi\n
            \n
            L'interview doit essayer de dégager quels seront les utilisateurs types du système, dans quel environnement il vont l'utiliser et quels sont leurs besoins. Il faut rendre le participant aussi actif que possible lors de l'interview.\n
            \n
            On peut compléter les interviews par un questionnaire (en ligne) qui permet d'atteindre un plus grand nombre de personnes. Le questionnaire peut faire émerger des tendances générales, ce qui est impossible avec un petit nombre d'interviews.\n
            \n
            ## Observation\n
            \n
            La collecte de données par observation consiste à se rendre sur le lieu de travail de l'utilisateur pour comprendre son contexte de travail, son environnement social, les technologies utilisées, etc. Il y a de nombreuses manières de réaliser l'observation. On peut rester auprès de l'utilisateur et lui poser de temps à autre des questions; ou bien filmer l'utilisateur pendant un certain temps puis regarder et commenter le film avec l'utilisateur ou avec un spécialiste du domaine; ou encore prendre la place de l'utilisateur et faire le travail soi-même.\n
            \n
            La technique du focus group consiste à réunir une petite nombre d'utilisateurs potentiels (entre 6 et 12) et à engager une discussion informelle avec eux via un modérateur. Un modérateur veille à faire participer tout le monde, à recentrer la discussion sur le système. Le focus groupe sert à faire émerger les besoins, les désirs et de nouvelles idées.\n
            \n
            ## Créer un ensemble de personnages\n
            \n
            La création de personnages est une manière de représenter l'information collectée auprès des utilisateurs. Sur la base de ces informations on détermine un ou plusieurs profils d'utilisateurs types crédibles. L'idée de base est d'éviter de faire des moyennes mais au contraire de représenter la diversité des utilisateurs. On voit bien qu'il serait vain d'essayer de créer un personnage qui représenterait à la fois un jeune étudiant et un retraité.\n
            \n
            On définit précisément chaque personnage en donnant son âge, son sexe, une brève biographie, une photo. Par exemple\n
            \n
            ## exemple\n
            \n
            Pour le système de réservation en ligne d'une compagnie aérienne on définit deux personnages.\n
            \n
            **Marie Duparc** : 31 ans, voyage en classe affaires. Bilingue français-anglais, elle voyage régulièrement pour ses affaires. Elle aime bien regarder la section shopping et loisirs du site.\n
            \n
            **Georges Rémi** : 73 ans, voyage en classe économique. Commence à être âgé mais toujours très actif. Il est un peu gêné par un début d'arthrite dans ses doigts. Il n'a pas d'ordinateur à la maison et ne s'est jamais servi d'un ordinateur au travail.\n
            \n
            L'étape suivante consiste à associer un ou plusieurs scénarios d'utilisation à chaque personnage, comme nous le verrons dans le chapitre suivant.\n
            \n
            © Uni. Genève - G. Falquet, J. Guyot, P. Roth
            """
          "images" => []
          "tables" => []
          "hyperlinks" => []
          "header" => null
          "footer" => null
          "dimensions" => [
            "dpi" => 200
            "height" => 2339
            "width" => 1654
          ]
        ]
      ]
      "ocrName" => "mistral"
      "model" => "mistral-ocr-latest"
      "documentAnnotations" => null
      "usageInfo" => [
        "pages_processed" => 4
        "doc_size_bytes" => 86315
      ]
      "documentId" => 970
    ]
  ]
]