u des informateurs clés par téléphone

Le problème que vous allez aborder est lié à l'activité INTERNE de l'organisation sur laquelle vous
travaillez. Peut-être que les gens de cette entreprise ont besoin d'une nouvelle technologie, ou qu'ils ont
investi dans quelque chose qui n'est pas utilisé/sous-utilisé, ou simplement qu'ils ont fusionné/grandi et
ont besoin de nouvelles solutions pour organiser le travail. Tout ce que vous lirez dans les chapitres 1, 2
et 3 du manuel peut être pertinent ici.

Vous allez formuler vos propres recommandations pour cette entreprise. Attention, vous devez montrer
la rigueur et la pertinence de vos propres solutions, ne vous contentez pas d'expliquer ce que
l'entreprise a décidé de faire pour résoudre le problème avant que vous ne frappiez à leur porte ! Il s'agit
de gérer les technologies numériques, donc si vos recommandations s'arrêtent à " l'entreprise X devrait
mettre en place un système ERP ", vos prospects ne seront pas du tout impressionnés... Ils ont besoin de
savoir pour le mettre en place et ce que cela va changer dans leurs processus, comment les gérer, etc.

Votre essai ne dépassera pas 2 300 mots (interligne 1,5 ; Times New Roman taille 12, A4 portrait), sans
compter la page de couverture, la liste de références et les annexes. Vous écrirez le nombre de mots
avant la liste de référence. · Sur la page de garde, vous indiquerez (1) le titre de la dissertation
individuelle, (2) votre nom et votre numéro d'étudiant, (3) l'année académique et (4) le nom de votre
professeur · Votre liste de références doit comprendre au moins 5 éléments, outre le cours du manuel
Systèmes d'information pour managers. Copier le manuel est un problème de plagiat et sera sévèrement
sanctionné. Vos références proviendront de médias spécialisés (par exemple HBR, MIT Tech Review) et
de sources académiques

Cornford, T., & Smithson, S. (2005). Project research in information systems : a student's guide.
Macmillan International Higher Education.

Vous téléchargerez votre fichier au format PDF dans la boîte de soumission correspondante sur Moodle.
Toute essai soumis par un autre canal ne sera pas noté. · Vous enregistrerez votre fichier sous le nom de
STUDENTNAME_PROFNAME_2022_CASE

Présentation du cas

Problématique

Analyse situation actuelle

Recommandation

L’entreprise Eugen Systems est un studio de développement de jeu vidéo fondé en.
SI adapté à la nature complexe et itérative de la production du produit vidéoludique. Objet technique
central : la build.

SI parvient à connecter designer, lignes de codes avec sauvegardes régulières, code couleur chacun
laisse. Bien intégré pour hautement qualifié et lors production interne, manque testeurs une fois le jeu
sortie

Problématique : comment mieux intégrer le rôle itératif central des testeurs interne et externalisé une
fois le jeu sorti ?

Recommandation : intégrer davantage les testeurs + externaliser via twitch, en utilisant API et détection
langage chat type bug ou quoi pour tout de suite pouvoir intervenir. Tirer partie du jv global game et
mises à jours. Externalisation et automatisation par greffe à twitch.
« dispositifs alogithimiques complexes et interactifs » « variété de spécialisations hautement qualifiées,,
précaires cet assemblages de techniques myriades de défaillance » « build version intermédiaires du
produit » « alertes pannes et défaut

« global game, jeux comme services Kerr, 2017 »

Meades : public expertise repère les bugs, lourdes conséquences commerciales

Travail créatif incertitude Menger

des testeurs en interne, prenant à contre-courant la généralisation du

recours à l’externalisation pour ces travaux peu qualifiés (Kerr, 2017, p. 194-
195)
Dans le numérique en particulier, les conditions d’inscription et
d’effacement des participations productives se transforment avec
l’introduction de nouvelles médiations technologiques. Les « petites mains »
pourtant indispensables à la production de données et à la stabilité des
infrastructures digitales se multiplient (Denis et Pontille, 2012 ; Cohn, 2019). 
Que se joue-t-il dans la production de ces données informationnelles, du
point de vue de leur extraction, de leur codification, de leur circulation et de
leur usage ? 
Le développement de jeux vidéo, par nature interdisciplinaire, fait
intervenir quatre catégories d’acteurs (Kerr, 2006) : les ingénieurs
(programmeurs), les designers, les artistes et le management. Au sein de
chacune d’elles se logent de multiples corps professionnels fortement
spécialisés qui ne partagent pas toujours de langage et de savoir-faire
communs (Whitson, 2017), ni même d’outils (le nombre de supports de
travail est conséquent : interfaces variées du moteur de jeu, logiciels de
création de données – algorithmes, éléments graphiques, animations ou
encore sons –, documents textuels, tableurs, etc.). 
Enjeu de centralisation de l’information
Dans cet environnement, un objet numérique joue un rôle fondamental, en
ce qu’il est le point d’observation central de la rencontre de ces actes
productifs : la build. Elle est une simulation intermédiaire du produit,
contenant la dernière version des données créées et intégrées, ainsi que le
code d’exécution nécessaire à la lecture et à l’interprétation de celles-ci. Afin
qu’une version actualisée du travail effectué soit toujours disponible, elle est
générée automatiquement trois fois par jour. À ce titre, la build peut être
considérée comme un « objet intermédiaire » (Jeantet, 1998 ; Vinck, 1999), en
ce qu’elle participe à la structuration et la coordination des activités. Comme
Dominique Vinck et Alain Jeantet le développent, l’objet intermédiaire, ici
la build, est à la fois le siège de processus de représentation (elle matérialise
les intentions des concepteurs, leurs habitudes de travail ou de pensée, leurs
rapports et leurs interactions, leurs perspectives et les compromis qu’ils ont
établis) et le véhicule d’une vision en cours de cristallisation à partir duquel
les acteurs projettent leurs actions. Cette matérialisation engendre trois
dynamiques :

 la première repose sur la mise en commun des contributions des

différents développeurs. La build, en tant que carrefour du travail
parallèle effectué par une myriade d’acteurs, matérialise les
incompatibilités qui n’ont pas pu être anticipées de manière abstraite,
mais également les désaccords et les négociations inachevées
(Whitson, 2017) ;
 la deuxième dynamique est liée à la multiplicité des environnements
technologiques : qu’elle provienne initialement d’une interface du
moteur du jeu ou d’un logiciel de création graphique ou sonore, la
contribution de chacun va passer d’un espace local à un objet
technique collectif. Ces transferts engendrent de multiples résistances
(O’Donnell, 2014, p. 128), puisqu’ils placent chaque participation dans
un nouveau réseau de contraintes et d’interdépendances ;
 la dernière découle de l’interactivité propre aux jeux vidéo. Puisque les
possibilités de mouvement et d’action du joueur sont innombrables,
 leurs anticipations par les développeurs ne sont souvent que partielles.
La build, dès lors, est l’espace où se cristallisent ces anticipations
incomplètes ou ratées et où se matérialisent les cas d’action n’ayant
pas été pris en compte (puisqu’elle est le premier environnement
« jouable » en « conditions réelles »).
eux horizons temporels se croisent : celui du présent du développement,
puisque la build doit rester suffisamment stable et fonctionnelle pour que
chacun puisse analyser son travail « en contexte », et celui du futur de la
commercialisation, puisqu’aucune défaillance majeure ne doit subsister lors
de la prise en main par le consommateur final. La réactualisation
permanente de la connaissance de son état est, dès lors, un enjeu fort du
développement.
Ils jouent le rôle d’un utilisateur fictif qui alerte l’équipe de développement
sur les éléments venant empêcher l’expérience ou en amoindrir la qualité :
déclenchement d’action incomplet ou inadapté, absence d’éléments de
contenu (graphiques, sonores, animations, etc.), freins à la progression,
manque de stabilité du code, etc. Cette recherche de bugs est principalement
effectuée par le biais de la méthode du « test destructif », dans lequel le
testeur explore un niveau jusqu’à rencontrer une défaillance, qui doit être
notifiée au reste de l’équipe. Pour ce faire, un logiciel spécialisé de gestion de
base de données de bugs (tel que Jira ou Mantis Bug Tracker), est mis à leur
disposition, dans lequel chacune des anomalies est numérotée et décrite.
Une fois créé, ce « ticket » est assigné à une équipe, qui devra se charger de
résoudre la défaillance (ou de le réassigner à son tour si elle estime que sa
résolution sort de son champ de compétence).
Pourtant, cette particularité met aussi au jour la porosité de la frontière
entre actes de création et de maintenance, l
Les testeurs constituent une interface sensible entre le monde ludique en
construction et les autres développeurs. Par leur travail d’exploration et
d’alerte, ils sont le premier chaînon de la stabilisation et de la consolidation
du produit. Ils amorcent le processus de structuration de la perception
collective des défaillances. En créant des artefacts numériques qui
impliquent les acteurs au gré de leur circulation et de leur catégorisation, ils
autorisent, non sans négociations et frottements, la coexistence de mondes
sociaux épistémiquement distincts. Ces actes d’inscriptions successifs
« aplatissent » (Latour, 1985) progressivement un réel trop imbriqué pour
être intelligible, tout en faisant émerger le relief de la représentation. En
outre, une fois stabilisés (stabilité, nous l’avons vu, toujours relative), ces
objets se fondent dans l’écologie ordinaire de l’action productive et outillent
de multiples pratiques grâce à leurs propriétés représentationnelles et
référentielles. Ce travail d’articulation permet de faire tenir ensemble
l’hétérogénéité des contributions, des outils et des objets techniques qui
habitent le studio, mais aussi la variété des séquences et échelles d’activité.

Ne répond qu’imparfaitement aux besoins de tratement de l’information

prévus
But d’un SI : collecter, traiter, stocker et diffuser les informations
Améliorer efficience et efficacité
Les systèmes d'information sont formels, des systèmes sociotechniques et organisationnels conçus pour
collecter, traiter, stocker et diffuser des informations. (Picolli,

Matériel hardware : servers physiques / tours de disques durs / ordinateurs / consoles de test

Logiciel : Jira, Discord

Formalisation vs discussions informelles et éparssent (surtout télétravail)

Leads équipes / programmeurs / managers / clients finaux

Structure : décentralisées, si centralise

Informer > automatiser et transformer

Culture d’entreprise : par projets et en réseaux boltanski

Effets systémiques

Prendre en compte hiérarchie : build test doivent impliquer haut et bas de la hiérarchie via testeurs

RPA ! réingénieurie des processus métier

Vise intégration des données, meme base de donnée, référentiel commun

Intégration des applications : jira et discord et logiciel de codage

ERP entreprise ressource planning : build

CRM : gestion de la relation client