5 questions à se poser avant d'intégrer l'IA dans la localisation de jeux

Les questionnements sur l'intégration de l'IA dans les jeux vidéo portent le plus souvent sur ses capacités : que sait faire cet outil? Peut-il accélérer notre processus de production et en réduire les coûts?

L'IA peut en effet permettre de relever ces deux défis, mais, plus rapide et moins cher ne signifie pas meilleur.

En effet, l'IA ne fait pas qu'amplifier votre production. Elle amplifie tout : chaque lacune, chaque présupposé, chaque point faible de votre processus de travail.

Donc, avant de déployer l'IA dans la localisation de jeux, il est important de savoir précisément à quel niveau vous souhaitez l’intégrer et comment adapter votre processus de production en conséquence.

Voici 5 questions qui vous aideront, ainsi que votre équipe, à déterminer si la localisation assistée par l'IA est adaptée à votre processus de développement de jeux vidéo, en vous indiquant notamment les pièges courants et les moyens de les éviter.

1. Quel problème de production voulons-nous résoudre?

Avant de déployer l'IA, les studios de jeux devraient définir le problème de production à résoudre. L'IA peut présenter de réels avantages pour les équipes confrontées à des échéanciers serrés et à des budgets encore plus réduits :

1. Elle permet de gagner en rapidité. Chez Side, nous avons constaté que la traduction assistée par l'IA réduisait le temps de traduction de 40 % et les coûts de 30 % au maximum, selon le contenu, la combinaison linguistique et le niveau de révision humaine nécessaire.
2. Elle permet de gagner en efficacité à grande échelle. En effet, la localisation d'un jeu live ne se fait pas d'un seul coup. Notes de mise à jour, descriptions d'événements, contenu saisonnier et mises à jour de la boutique : le flux ne s'arrête jamais et se double à chaque nouvelle langue.
3. Elle permet d'élargir la portée du jeu. Des marchés qui ne justifiaient pas auparavant l'affectation d'effectifs dédiés deviennent viables. Un jeu peut ainsi être commercialisé là où cela n'était pas possible auparavant, puis rester à jour à mesure que du nouveau contenu est publié.

Mais l'outil n'est que la partie émergée de l'iceberg. Pour en tirer parti, encore faut-il bien intégrer l'IA et s'assurer qu'elle est réellement adaptée aux besoins de votre jeu.

2. L'IA est-elle adaptée au processus de localisation de notre jeu?

L'IA est adaptée lorsque le type de contenu, le niveau de risque, le processus de révision et les dépendances en aval permettent son utilisation.Elle n'est pas forcément adaptée par défaut, même si l'outil est capable de produire des résultats.

Les technologies innovantes sont, par nature, révolutionnaires. Si l'IA ouvre la voie à de nouvelles possibilités, elle crée également de nouvelles lacunes, met en évidence celles qui existaient déjà, et en amplifie la portée. En effet, les systèmes sur lesquels ces outils sont déployés n'ont pas été conçus pour la prendre en compte.

C'est pourquoi la capacité technique seule est insuffisante. La plupart des décisions en matière d'IA sont prises en fonction d'hypothèses sur les performances : peut-elle traduire ce contenu? Peut-elle générer ces résultats? La réponse est habituellement oui, donc l'outil est déployé. Mais la capacité technique ne concerne que l'outil pris isolément. La question la plus importante à poser concerne l'outil en contexte : quel sera l'impact de cet outil sur le reste de notre processus de localisation?

En effet, l'adéquation n'est pas une caractéristique de l'outil en soi, mais bien de celle du système dans lequel il s'inscrit. Même lorsque les outils fonctionnent comme prévu, les défaillances les plus courantes tiennent à leur utilisation, à la répartition des responsabilités et à la gouvernance : la façon dont les résultats sont utilisés, la personne habilitée à les valider et le fait que les intervenants en aval sachent ou non qu'une machine a pris la décision.

Un outil performant, intégré à un système non conçu pour le prendre en compte, ne réduit pas les risques. Il redimensionne tout ce qui s'y trouve déjà.

3. Que pourrait-il se passer lorsque l'IA se trompe?

Lorsque l'IA commet des erreurs de localisation, celles-ci peuvent se propager rapidement. En effet, le résultat obtenu peut sembler fluide, cohérent et prêt à être intégré au jeu. Sans garde-fous appropriés, une erreur générée par l'IA peut en effet s'étendre à toute la production.

Voici deux exemples de risques liés à l'utilisation de l'IA à grande échelle dans la localisation de jeux vidéo que nous avons observés sur le terrain :

Étude de cas 1 : erreur de traduction fluide

Les textes de l'interface utilisateur d'un jeu devaient être localisés. Il s'agissait d'éléments classiques, tels que les chaînes de menu et les libellés courts; le genre de contenu à faible risque qui se prête facilement à la traduction par IA. L'une des phrases contenait le mot « set » à traduire.

Ce mot a une bonne dizaine de significations en anglais, mais chacune d'entre elles se traduit différemment en allemand :

L'IA n'a retenu qu'une seule option de traduction pour toutes les occurrences du mot « set ». Elle a fait le mauvais choix, traduisant un terme lié à une mécanique de jeu essentielle dans un sens totalement erroné.

Cette traduction est passée inaperçue. Le texte était fluide, grammaticalement correct et cohérent avec tout ce qui l'entourait. Le résultat a été approuvé selon tous les critères de vérification prévus dans le processus. L'erreur n'est apparue qu'une fois le jeu lancé.

Et comme elle était systématique, elle apparaissait partout. Un seul choix d'interprétation, reproduit à chaque occurrence du terme, avec exactement le même degré de certitude, qu'il soit erroné ou correct.

Étude de cas 2 :  Erreur dans les références officielles de la langue pivot

Le deuxième cas est d'ordre structurel.

Un titre japonais devait être localisé en français, en italien, en allemand et en espagnol. Plutôt que de traduire directement du japonais vers chaque langue, la production a utilisé l'anglais comme langue pivot – traduction du japonais vers l'anglais d'abord, puis de l'anglais vers les quatre langues européennes.

Le texte traduit en anglais ayant servi de texte pivot avait été généré par une IA. Les quatre équipes de traduction humaine en aval ont donc eu pour texte source le texte en anglais qu'elles ont traduit fidèlement et avec précision.

Une fois que le texte anglais généré par l'IA est devenu le texte source, il a cessé d'être une simple ébauche et est devenu le texte de référence officiel. Chaque choix d'interprétation intégré dans cette version anglaise – chaque ambiguïté que l'IA a résolue différemment – s'est retrouvé repris dans les quatre langues, puis traduit avec précision dans chacune d'entre elles. Les équipes ont tout fait correctement. Elles n'ont fait que traduire un texte source qui comportait des erreurs.

Lorsque les résultats générés par l'IA deviennent la référence à laquelle tout le monde se fie, ces erreurs ne sont plus circonscrites. Elles se généralisent.

4. Qui est garant de la source de référence?

La source de référence doit être placée sous la responsabilité d'une partie prenante clairement désignée, et non s'imposer par défaut du fait de la structure de la chaîne de production.

Par exemple, dans l'étude de cas de la langue pivot, l'anglais généré par l'IA est devenu la source de référence pour quatre équipes. Et c'est là que le bât blesse : personne n'en avait décidé ainsi. Personne n'a pris cette décision. Cette situation s'est produite par défaut, compte tenu du mode de conception de la chaîne de production.

Commencez par analyser la structure actuelle de votre chaîne de production. En général, le travail s'effectue par relais : chaque équipe est responsable de sa partie et la transmet à la suivante. Le processus est clairement défini, cloisonné, et pendant longtemps, cela a très bien fonctionné.

Mais l'IA fragilise cette structure. Le passage de relais suppose que la tâche transmise est achevée et fiable. Les décisions de l'IA prises en amont du processus sont souvent invisibles au moment où le travail est relayé à l'équipe qui les détecterait. Le choix à l'origine du problème a déjà été fait, et personne en aval ne sait qu'il faut chercher un problème. Là où les équipes ne travaillent pas de concert, les suppositions comblent les lacunes.

Deux éléments aggravent le problème :

1) Autonomie vs responsabilité

Les décisions en matière d'IA sont prises très en amont, souvent par quiconque travaille le plus avec l'outil. Les risques que ces décisions font peser sur la livraison ne se répercutent que bien plus tard, sur la personne responsable du résultat final. La responsabilité des chaînes de production peut varier selon les parties prenantes, tout comme celle en matière de qualité. Lorsque les personnes qui prennent les décisions et celles qui les exécutent ne sont pas les mêmes – et ne communiquent pas entre elles – le risque s'accumule dans l'espace qui les sépare.

2) Les règles invisibles

Un grand nombre de processus dépendent intrinsèquement de connaissances qui n'ont jamais été documentées : une solution de contournement connue d'une seule personne, une étape de révision effectuée de manière informelle, ou une règle de production qui existe dans la tête de quelqu'un plutôt que dans le cahier des charges.

Ce type de savoir permet d'assurer le bon fonctionnement d'une chaîne de production à petite échelle. Mais dès que l'IA intervient dans le flux de travail, ces dépendances invisibles deviennent plus difficiles à repérer et plus susceptibles de se reproduire. Le système continue de fonctionner, et l'IA le duplique fidèlement, avec toutes ses faiblesses.

Pour identifier ce genre de lacunes, essayez le test d'évaporation : retirez une personne, un preneur de décision, un système ou une hypothèse, et demandez-vous : « Qu'est-ce qui pourrait ne pas fonctionner? »  Si la réponse est « Beaucoup de choses », alors votre chaîne de production n'est pas suffisamment robuste. Les structures solides sont celles conçues en tenant compte de leurs points de vulnérabilité. Les modèles fragiles n'ont tout simplement pas encore été éprouvés.

Repenser le système : Des relais au chevauchement

La plupart des processus de développement de jeux reposent encore sur des relais : une équipe termine sa partie du travail, puis l'équipe suivante prend le relais.

Une telle approche fonctionne lorsque le contexte est bien défini. Mais dans les flux de travail intégrant l'IA, les décisions sont prises avant même que l'équipe suivante n'ait accès au contenu, d'où la nécessité accrue de transmettre les bonnes informations aux personnes concernées avant que le projet ne progresse outre mesure.

Comment y remédier? Par davantage de collaboration et une meilleure compréhension mutuelle entre les différents rôles.

Lorsque les rôles collaborent mieux, les erreurs sont détectées plus tôt, plus près de leur source. Par exemple :

• lorsqu'un responsable de la localisation comprend suffisamment bien les enjeux del'AQL
• lorsque les parties prenantes impliquées dans la prise de décision partagent une vision commune de la tâche à accomplir, des objectifs, des risques et des répercussions qu'une décision prise dans un domaine peut avoir sur un autre. Les équipes peuvent ainsi identifier les erreurs avant qu'elles ne se propagent, et non après coup. Les bonnes et les mauvaises décisions se propagent au sein de l'équipe de la même manière.

C'est ce qu'on appelle des modèles mentaux partagés : une connaissance suffisante des rôles connexes pour qu'aucune décision ne puisse traverser l'ensemble de la chaîne de production sans contrôle ni compromettre la fiabilité de celle-ci.

C'est cette collaboration qui transforme une succession de passages de relais en un système réellement capable de fonctionner avec l'IA. C'est également ainsi que les responsabilités cessent d'être fortuites : lorsque les rôles se recoupent, il y a toujours quelqu'un d'assez proche d'une décision pour en assumer la responsabilité.

Des équipes robustes de localisation et d'AQL assurent une complémentarité dans cinq domaines de compétence : expertise linguistique et culturelle, production et livraison, qualité et validation, compétences relationnelles et impact sur l'entreprise et les joueurs. Le niveau d'expertise varie selon les rôles, mais chaque membre de l'équipe doit avoir une bonne connaissance des rôles connexes.

5. Disposons-nous d'un cadre de gouvernance adapté aux décisions liées à l'IA?

Une gouvernance robuste en matière d'IA définit les domaines où l'IA peut être utilisée, les cas où ses résultats doivent être validés, qui est chargé de les approuver, et la manière dont les équipes en aval sont informées lorsque l'IA a influencé le travail.

La collaboration est le principe directeur. Un programme se définit par son application à grande échelle.

Pour garantir une gouvernance adéquate, une personne, telle qu'un responsable de programme de localisation, doit avoir une visibilité sur l'ensemble du processus de production et en assurer le pilotage. Cette personne détermine dans quels cas l'IA est autorisée à prendre une décision, dans quels cas ses résultats doivent être validés, et dans quels cas ne pas l'utiliser du tout.

L'équipe chargée du programme définit ces limites avant que les impératifs de production ne se fassent sentir. Elle intègre des points de contrôle tant qu'il est encore possible de réagir. Cela permet de garantir que la source de référence correspond bien aux attentes réelles de l'équipe de mise en œuvre. La décision est donc prise sciemment et non par défaut.

Cela favorise également la mise en place d'un modèle mental à tous les niveaux de la structure, de sorte que la connaissance des rôles connexes ne dépende pas uniquement de ceux qui se trouvent la posséder. Ainsi, les décisions prises par l'IA sont rendues visibles plutôt que dissimulées.

L'adoption de l'IA doit correspondre aux besoins de la chaîne de production

Adopter l'IA à tous les niveaux n'est en aucun cas une obligation. Vous pouvez prendre cette décision en fonction de vos besoins : selon le projet, le type de contenu ou l'étape du processus, afin d'adapter le niveau d'IA aux exigences de chaque tâche.

Les équipes qui réussissent sont celles qui ne cessent de se demander non seulement si l'IA peut faire le travail mais aussi si elles peuvent lui faire confiance.

Tel est le système sur lequel fonctionne Side. En matière de localisation, d'AQL, et d'audio localisé, nous assurons un pilotage à la fois au niveau du programme et de la production sur l'ensemble de la chaîne de production, afin que les décisions liées à l'IA restent visibles et que les risques liés à la livraison restent maîtrisés jusqu'au lancement.

Avec la bonne approche, l'IA fera ce qu'elle était censée faire dès le début : évoluer de manière contrôlée, sans amplifier les risques en parallèle.

Vous recherchez un programme et une équipe de localisation s'appuyant sur l'IA, capables de vous accompagner à grande échelle en toute confiance? Discutons-en!