Compétence 06 / 06 — BUT Informatique

Travailler dans une
équipe informatique

Acquérir, développer et exploiter les aptitudes nécessaires pour travailler efficacement dans une équipe informatique pluridisciplinaire. Composantes essentielles : s'engager dans des équipes pluridisciplinaires, accompagner l'évolution informatique, développer une communication efficace et collaborative.

Voir les preuves
2026
Vue d'ensemble

5 preuves,
du binôme
au professionnel.

Cinq collaborations aux contextes distincts : binômes académiques (MyPulse, Linux, WebGL), travail en équipe sur une application héritée (SAE S4), et collaboration professionnelle avec des interlocuteurs non-techniques (stage CENCA). Chaque contexte a développé des aptitudes différentes du travail pluridisciplinaire.

MyPulse — HOJA & SCHMITT SAE Linux — HOJA & SCHMITT WebGL — GUESMI & SCHMITT Stage CENCA SAE S4 — Équipe App Vote
Preuves d'acquisition
Preuve 01 / 05 — SAE S3, Binôme HOJA Valentin & SCHMITT Lilian

MyPulse — Développement full-stack en binôme

Développement coordonné d'une plateforme web complète avec production de 3 rapports cosignés. Travail en binôme : Git/GitHub, répartition des modules, revues de code mutuelles et coordination des livrables dans un délai contraint.

Git / GitHub Code review Répartition des tâches PHP 8.3

Contexte et ressources mobilisées

SAE S3 en binôme — développer ensemble une plateforme de vote musical et produire 3 rapports complémentaires. La coordination du code, des décisions d'architecture et des livrables rédactionnels était obligatoire. Outils : Git/GitHub (branches, pull requests), réunions de synchronisation régulières.

Activités et implication

  • Conception partagée : architecture MVC, modèle de données et workflow des contenus décidés ensemble
  • Répartition des modules : backend PHP vs. intégration Bootstrap/AJAX, admin vs. user-facing — selon affinités et compétences
  • Versionnement collaboratif : branches par fonctionnalité, pull requests, revues croisées avant merge
  • Co-rédaction : 3 rapports cosignés (24 + 8 + 14 pages) avec répartition des sections et relecture croisée

Apprentissages clés

  • Git en équipe : passer d'un usage solo à un workflow collaboratif (branches + PRs) — comprendre pourquoi les conflits de merge se produisent et comment les anticiper
  • Conventions partagées : deux développeurs sans charte commune produisent du code incompatible en style
  • Dépendances entre tâches : communiquer sur les interfaces et délais pour éviter les blocages mutuels

Traces sélectionnées

Historique Git collaboratif

Graphe des branches GitHub : branches par fonctionnalité, merge requests, commits des deux auteurs.

Rapports cosignés

Pages de couverture des 3 rapports avec les deux noms — cohérence du document malgré deux rédacteurs.

Rapport final (PDF) Retour en haut
Preuve 02 / 05 — SAE Linux, Binôme HOJA & SCHMITT

SAE Linux — Rédaction collaborative d'un guide technique

Production en binôme d'un guide d'administration Linux : structuration commune, répartition des sections, relecture croisée et harmonisation pour un document à voix unique cohérente.

Rédaction collaborative Documentation technique Relecture croisée

Contexte et ressources mobilisées

SAE Linux — deux personnes qui rédigent en parallèle doivent produire un document à voix unique. Le défi : cohérence du style, du niveau de détail et de la terminologie malgré les contributions individuelles. Plan commun défini en amont, normes rédactionnelles partagées.

Activités et implication

  • Structuration commune : plan du guide défini ensemble avant toute rédaction
  • Répartition des sections : chaque membre rédige ses sections en autonomie, puis partage pour intégration
  • Relecture croisée : corrections d'exactitude technique et harmonisation du style
  • Session d'harmonisation : unification du style, vérification des exemples, progression pédagogique validée collectivement

Apprentissages clés

  • Écriture collaborative : sans plan commun et normes définies en amont, le document final est hétérogène
  • Relecture technique : distinguer une erreur factuelle (commande incorrecte) d'une préférence de style
  • Complémentarité : les domaines de confort de chacun ont enrichi la couverture du document global

Traces sélectionnées

Guide Linux complet (cosigné)

Document de 8 pages HOJA & SCHMITT — couverture complète sans rupture de style entre les sections rédigées par chacun.

Cohérence entre sections

Extraits de sections rédigées par chacun montrant l'homogénéité du niveau de détail et du format des exemples.

Guide Linux (PDF) Retour en haut
Preuve 03 / 05 — R4-13, Binôme GUESMI Djibril & SCHMITT Lilian

WebGL Tableau Médiéval — Développement 3D en binôme

Développement d'une scène 3D Three.js avec répartition des modules 3D (objets, textures, effets), intégration d'un modèle OBJ externe, et validation progressive via une checklist partagée de 40+ critères.

Three.js Intégration de code Checklist partagée Répartition modules

Contexte et ressources mobilisées

Module R4-13, encadré par le prof. Villard — créer une scène médiévale Three.js en binôme. Checklist de 40+ critères techniques comme outil de validation commun. La complexité (géométries, textures, effets) rendait la répartition des modules indispensable.

Activités et implication

  • Répartition des modules : attribution des objets et effets selon les affinités — chaque module exposant des fonctions claires pour que l'autre puisse les intégrer
  • Intégration OBJ : import du casque médiéval (OBJLoader + MTLLoader) — synchronisation nécessaire sur position, échelle et matériaux pour cohérence visuelle
  • Checklist comme outil de revue : chaque critère coché = fonctionnalité acceptée par les deux, pas seulement l'auteur
  • Tests croisés : chaque membre teste les modules de l'autre pour détecter les problèmes d'intégration

Apprentissages clés

  • Intégrer le code d'un pair demande de le comprendre — pas seulement de le copier
  • Interfaces de code : fonctions bien nommées avec paramètres clairs = l'autre membre peut utiliser le module sans connaître son implémentation interne
  • La checklist devient le contrat entre les deux membres sur ce que «fini» signifie pour chaque critère

Traces sélectionnées

Scène WebGL intégrée — GUESMI & SCHMITT Scène 3D intégrée

Objets des deux membres (table, casque, verre, bougie, miroir) fusionnés dans une scène visuellement cohérente.

Checklist et répartition des modules

20+ critères validés collectivement et structure objectJS/ (table.js, wine_glass.js…) montrant la répartition claire des responsabilités.

Ouvrir le projet WebGL Retour en haut
Preuve 04 / 05 — Stage CENCA, 2025-2026

Stage CENCA — Collaboration sous supervision et avec les utilisateurs

Travail en contexte professionnel pluridisciplinaire : supervision par un géomaticien (expert métier, non-développeur) et réunions régulières avec les membres de l'association pour valider les fonctionnalités de l'application Atlas face aux contraintes utilisateurs réelles.

Collaboration pluridisciplinaire Communication non-technique Retours utilisateurs Angular / Node.js

Contexte et ressources mobilisées

CENCA — application Atlas développée pour des géomaticiens et du personnel administratif. Mon maître de stage est géomaticien : expert du métier et des données géographiques, mais pas développeur. Des réunions régulières avec les membres de l'association permettaient de présenter l'avancement et de vérifier la conformité aux contraintes réelles des utilisateurs.

Activités et implication

  • Supervision par un géomaticien : comprendre les exigences métier exprimées sans vocabulaire technique — traduire des besoins fonctionnels en spécifications développables
  • Réunions avec l'association : présentation des fonctionnalités en cours, collecte des retours utilisateurs, ajustements des priorités selon les contraintes remontées
  • Adaptation de la communication : présenter des choix techniques (architecture Angular, API géographiques) de façon compréhensible pour des non-développeurs
  • Validation des livrables : chaque module (actes, parcelles) validé par les futurs utilisateurs avant d'être intégré définitivement

Apprentissages clés

  • Travailler avec un expert non-développeur : les exigences métier sont valides même si elles ne sont pas formulées en termes techniques — à moi de faire le pont
  • Les retours utilisateurs en cours de projet évitent les développements hors-cible : une réunion à mi-parcours vaut mieux qu'une correction en fin de projet
  • Communication adaptée : le même résultat s'explique différemment selon que l'interlocuteur est géomaticien, administratif ou jury académique

Traces sélectionnées

Site naturel CENCA — contexte du stage Contexte CENCA — équipe pluridisciplinaire

Collaboration entre un développeur stagiaire, un géomaticien (maître de stage) et les membres de l'association — profils non-techniques.

Réunions de validation — rapport de stage

Présentation des modules aux membres de l'association, retours utilisateurs collectés et ajustements réalisés en conséquence — documentés dans le rapport de stage.

Rapport de stage (PDF) Retour en haut
Preuve 05 / 05 — SAE S4, Équipe pluridisciplinaire

App Vote SAE S4 — Travail en équipe sur application héritée

Travail en équipe pour identifier collectivement les failles d'une application de vote héritée et répartir les corrections à apporter : performance, robustesse, sécurité et accessibilité — 29 points de la grille traités en collaboration.

Audit collaboratif Répartition des tâches PHP / MariaDB OWASP

Contexte et ressources mobilisées

SAE S4 — hériter d'une application de vote existante et travailler en équipe pour l'améliorer selon une grille de 29 critères (sécurité, performance, robustesse, accessibilité). La première étape était collective : identifier ensemble les problèmes avant de se répartir les corrections.

Activités et implication

  • Audit collectif : lecture commune du code hérité, identification des failles par catégorie — chaque membre apporte son angle (sécurité, performance, infra, robustesse)
  • Répartition des corrections : attribution des 29 points de la grille selon les compétences et disponibilités, avec points de synchronisation pour éviter les conflits
  • Intégration : les corrections de chaque membre devaient fonctionner ensemble — tests croisés et vérification de la cohérence du code final
  • Score global : passage de l'application initiale (multiple failles) à une version robuste, validée par les outils de mesure (Observatory, Lighthouse, EXPLAIN)

Apprentissages clés

  • L'audit collectif est plus complet qu'un audit individuel : chaque membre repère des problèmes que les autres n'ont pas vus
  • Répartir des corrections sur une base de code commune nécessite de communiquer sur les interfaces et les dépendances entre les changements
  • Travailler en équipe sur du code hérité exige plus de coordination que sur du code vert — chaque modification peut impacter les autres

Traces sélectionnées

Rapport SAE S4 — Répartition des tâches

Les 29 corrections documentées avec attribution par membre, justification technique et métriques avant/après.

Score final — Application améliorée

Mozilla Observatory F → A, Lighthouse amélioré : résultat du travail d'équipe sur les 4 axes (sécurité, performance, robustesse, accessibilité).

Rapport SAE S4 (PDF) Retour en haut
← C5 — Conduire un projet C6 / 06 ↩ Toutes les compétences