574 lines
20 KiB
Typst
574 lines
20 KiB
Typst
// #import "@preview/showybox:2.0.1": showybox
|
||
|
||
#set document(
|
||
title: "Cahier des charges - Projet de fin d'études",
|
||
author: "Votre nom",
|
||
date: datetime.today(),
|
||
)
|
||
|
||
#set page(
|
||
paper: "a4",
|
||
margin: (x: 2.5cm, y: 2cm),
|
||
numbering: "1",
|
||
header: align(right)[
|
||
_Cahier des charges - Projet de fin d'études_
|
||
],
|
||
)
|
||
|
||
#set text(
|
||
font: "Liberation Serif",
|
||
size: 12pt,
|
||
lang: "fr",
|
||
)
|
||
|
||
#set heading(numbering: "1.1.")
|
||
|
||
#show heading: it => [
|
||
#v(1em)
|
||
#set text(weight: "bold")
|
||
#it
|
||
#v(0.5em)
|
||
]
|
||
|
||
#align(center)[
|
||
#v(4cm)
|
||
#text(size: 20pt, weight: "bold")[
|
||
CAHIER DES CHARGES
|
||
]
|
||
|
||
#v(3cm)
|
||
|
||
#text(size: 16pt)[
|
||
Projet de fin d'études
|
||
]
|
||
|
||
#v(1.5cm)
|
||
|
||
#text(size: 14pt)[
|
||
Jumeau numérique de la plateforme \
|
||
DIWII
|
||
]
|
||
|
||
#v(4cm)
|
||
|
||
#grid(
|
||
columns: (1fr, 1fr),
|
||
column-gutter: 2cm,
|
||
[
|
||
*Étudiants :* \
|
||
Paul Roost \
|
||
Axelle Destombes \
|
||
Alexis Bruneteau
|
||
],
|
||
[
|
||
*Encadrant :* \
|
||
Bruno CHAVAGNEUX \
|
||
Responsable plateforme pour DIWII
|
||
]
|
||
)
|
||
|
||
#v(5.5cm)
|
||
|
||
#text(size: 12pt)[
|
||
#datetime.today().display("[day]/[month]/[year]")
|
||
]
|
||
]
|
||
|
||
#pagebreak()
|
||
|
||
= Table des matières
|
||
|
||
#outline(indent: auto)
|
||
|
||
#pagebreak()
|
||
|
||
= Introduction
|
||
|
||
== Contexte du projet
|
||
Dans le cadre de l'industrie 4.0, les plateformes éducatives de demonstration jouent un rôle crucial dans la formation des futurs ingénieurs et techniciens. Ces plateformes permettent d'enseigner les concepts de l'automatisation, de l'IIoT. Le développement d'un jumeau numérique de ces plateformes éducatives ouvre de nouvelles possibilités pédagogiques : simulation en temps réel, expérimentation sans risque, et formation à distance.
|
||
|
||
== Problématique
|
||
Les plateformes de production éducatives actuelles présentent plusieurs limitations :
|
||
- Accès limité aux équipements physiques pour tous les étudiants
|
||
- Difficultés d'extraction et de standardisation des données des capteurs industriels
|
||
- Manque d'outils d'analyse temps réel pour l'apprentissage
|
||
- Absence de visualisation 3D pour comprendre les processus complexes a distance
|
||
- Besoin d'agrégation de données pour une vue d'ensemble pédagogique
|
||
- Préparation insuffisante aux enjeux de la téléopération industrielle
|
||
|
||
== Objectifs généraux
|
||
- Créer un jumeau numérique fidèle de la plateforme de production éducative
|
||
- Développer un système d'extraction de données capteurs en temps réel
|
||
- Implémenter une analyse temps réel pour l'amélioration des KPI
|
||
- Préparer l'infrastructure pour la téléopération future
|
||
|
||
= Analyse de l'existant
|
||
|
||
== État de l'art
|
||
|
||
=== Jumeaux numériques industriels
|
||
|
||
Les jumeaux numériques représentent une évolution majeure dans l'industrie 4.0. Selon Gartner, un jumeau numérique est "une représentation numérique d'une entité ou d'un système du monde réel". Les principales entreprises comme Siemens avec leur plateforme MindSphere, General Electric avec Predix, ou encore PTC avec ThingWorx, proposent des solutions de jumeaux numériques pour l'industrie.
|
||
|
||
*Siemens Digital Twin :* Intègre la CAO, la simulation et les données IoT pour créer des modèles prédictifs. Utilisé dans l'automobile et l'aéronautique.
|
||
|
||
*Azure Digital Twins (Microsoft) :* Plateforme cloud permettant de créer des graphiques de connaissances d'environnements physiques entiers.
|
||
|
||
*ANSYS Twin Builder :* Spécialisé dans la simulation multi-physique temps réel pour les systèmes complexes.
|
||
|
||
=== Plateformes éducatives industrielles
|
||
|
||
*Festo Didactic :* Leader mondial des plateformes de formation industrielle avec des systèmes comme CP Factory et MPS (Modular Production System). Leurs solutions intègrent des technologies Industry 4.0 mais manquent de capacités de jumeau numérique avancées.
|
||
|
||
*Schneider Electric EcoStruxure :* Propose des solutions IoT industrielles avec des capacités d'analyse mais principalement orientées production réelle.
|
||
|
||
*Rockwell Automation Connected Components Workbench :* Environnement de développement pour l'automatisation mais limité en termes de simulation 3D immersive.
|
||
|
||
=== Technologies de simulation 3D industrielle
|
||
|
||
*Unity Reflect :* Plateforme de réalité mixte pour l'industrie permettant la visualisation 3D de données BIM et CAO.
|
||
|
||
*Unreal Engine pour l'industrie :* Utilisé par BMW, Audi pour la visualisation de chaînes de production et la formation.
|
||
|
||
*NVIDIA Omniverse :* Plateforme de collaboration 3D temps réel intégrant simulation physique et rendu photoréaliste.
|
||
|
||
=== Extraction et analyse de données industrielles
|
||
|
||
*OPC UA (Open Platform Communications Unified Architecture) :* Standard industriel pour l'interopérabilité machine-to-machine, adopté par la majorité des équipementiers.
|
||
|
||
*MQTT et Apache Kafka :* Protocoles de messagerie temps réel largement utilisés pour l'IIoT.
|
||
|
||
*InfluxDB et TimescaleDB :* Bases de données temporelles optimisées pour les données de capteurs industriels.
|
||
|
||
*Grafana et Kibana :* Solutions de visualisation temps réel des données industrielles.
|
||
|
||
=== Limitations identifiées
|
||
|
||
Bien que ces technologies soient matures individuellement, leur intégration dans un contexte éducatif présente des défis :
|
||
- Coût élevé des solutions commerciales pour l'éducation
|
||
- Complexité d'intégration entre les différentes briques technologiques
|
||
- Difficultés d'accès aux données en temps réel sur les plateformes éducatives existantes
|
||
|
||
== Analyse critique
|
||
|
||
=== Forces des solutions existantes
|
||
|
||
*Solutions industrielles matures :*
|
||
- Technologies éprouvées en environnement industriel réel
|
||
- Standards ouverts bien établis (OPC UA, MQTT)
|
||
- Écosystèmes riches avec de nombreux fournisseurs
|
||
- Capacités de traitement temps réel démontrées à grande échelle
|
||
|
||
*Plateformes éducatives robustes :*
|
||
- Matériel pédagogique de qualité industrielle (Festo, Schneider)
|
||
- Programmes de formation structurés et validés
|
||
- Support technique et documentation extensive
|
||
- Intégration avec les cursus de formation technique
|
||
|
||
*Outils de simulation avancés :*
|
||
- Moteurs 3D performants (Unity, Unreal Engine)
|
||
- Capacités de rendu photoréaliste
|
||
- Support VR/AR pour l'immersion
|
||
- Interfaces utilisateur sophistiquées
|
||
|
||
=== Faiblesses et lacunes identifiées
|
||
|
||
*Coût et accessibilité :*
|
||
- Solutions commerciales onéreuse pour les établissements d'enseignement
|
||
- Licensing complexe et frais de maintenance élevés
|
||
- Formation requise pour les enseignants sur des outils propriétaires
|
||
- Dépendance vis-à-vis de fournisseurs spécifiques
|
||
|
||
*Intégration et interopérabilité :*
|
||
- Cloisonnements technologiques entre les différentes briques
|
||
- Protocoles de communication non standardisés entre certains équipements
|
||
- Complexité d'intégration des données hétérogènes
|
||
- Absence d'API unifiées pour l'accès aux données
|
||
|
||
*Adaptation pédagogique :*
|
||
- Solutions conçues pour la production, pas pour l'apprentissage
|
||
- Manque de scénarios pédagogiques progressifs
|
||
- Absence d'outils d'évaluation intégrés
|
||
- Interface souvent trop complexe pour des étudiants
|
||
|
||
|
||
=== Opportunités d'amélioration
|
||
|
||
- Développement de solutions open-source adaptées à l'éducation
|
||
- Intégration native de fonctionnalités pédagogiques
|
||
- Optimisation pour des environnements multi-utilisateurs
|
||
- Réduction des coûts par une approche modulaire et évolutive
|
||
|
||
== Positionnement du projet
|
||
|
||
=== Valeur ajoutée distinctive
|
||
|
||
Notre projet se positionne comme une solution innovante qui comble les lacunes identifiées dans l'état de l'art, en proposant un jumeau numérique spécifiquement conçu pour l'enseignement industriel.
|
||
|
||
=== Différenciation par rapport à l'existant
|
||
|
||
|
||
*Architecture ouverte et modulaire :*
|
||
- Utilisation de technologies open-source pour réduire les coûts
|
||
- Architecture microservices permettant une évolutivité flexible
|
||
- Standards ouverts pour garantir l'interopérabilité
|
||
- Capacité d'intégration avec les équipements existants de l'établissement
|
||
|
||
*Innovation technique :*
|
||
- Synchronisation temps réel entre le jumeau numérique et la plateforme physique
|
||
- Agrégation de données pour une futur analyse prédictive des données
|
||
- Création / Amelioration des KPI performances, qualités et opérationnelles
|
||
- Système d'extraction de données unifié et standardisé
|
||
|
||
=== Apports innovants
|
||
|
||
*Convergence technologique :*
|
||
Le projet fait converger les technologies de jumeau numérique et l'IIoT dans une solution unifiée et accessible.
|
||
|
||
*Démocratisation de l'industrie 4.0 :*
|
||
En offrant un accès à ces technologies à travers un dispositif démonstratif, le projet illustre concrètement les enjeux de l’industrie 4.0.
|
||
|
||
*Approche expérimentale sécurisée :*
|
||
Le jumeau numérique permet à l'utilisateur d'expérimenter sans risque sur divers scénarios complexes.
|
||
|
||
*Préparation à la téléopération :*
|
||
Le projet pose les bases technologiques pour l'évolution future vers la téléopération industrielle.
|
||
|
||
= Spécifications fonctionnelles
|
||
|
||
== Fonctionnalités principales
|
||
|
||
#rect(
|
||
width: 100%,
|
||
stroke: blue + 1pt,
|
||
inset: 10pt,
|
||
radius: 5pt,
|
||
fill: blue.lighten(95%),
|
||
[
|
||
#text(weight: "bold", fill: blue)[Fonctionnalité 1 : Extraction de données capteurs]
|
||
|
||
*Description :* Système d'extraction et de standardisation des données provenant des capteurs de la plateforme physique (température, pression, position, vitesse, etc.) via les systèmes de contrôle existants.
|
||
|
||
*Critères d'acceptation :*
|
||
- Connexion aux systèmes de contrôle de la plateforme DIWII
|
||
- Extraction temps réel des données capteurs
|
||
- Formatage standard des données (JSON, OPC UA, ou protocole spécifique)
|
||
- Gestion des erreurs de communication
|
||
- Log des données pour traçabilité
|
||
|
||
*Priorité :* Haute
|
||
]
|
||
)
|
||
|
||
#rect(
|
||
width: 100%,
|
||
stroke: purple + 1pt,
|
||
inset: 10pt,
|
||
radius: 5pt,
|
||
fill: purple.lighten(95%),
|
||
[
|
||
#text(weight: "bold", fill: purple)[Fonctionnalité 2 : Agrégation et vue globale]
|
||
|
||
*Description :* Système d'agrégation des données provenant de multiple sources pour fournir une vue d'ensemble complète de la chaîne de production.
|
||
|
||
*Critères d'acceptation :*
|
||
- Collecte de données multi-sources
|
||
- Base de données temporelle
|
||
- API de requête de données
|
||
- Rapports automatisés
|
||
- Interface de visualisation globale
|
||
|
||
*Priorité :* Haute
|
||
]
|
||
)
|
||
|
||
#rect(
|
||
width: 100%,
|
||
stroke: green + 1pt,
|
||
inset: 10pt,
|
||
radius: 5pt,
|
||
fill: green.lighten(95%),
|
||
[
|
||
#text(weight: "bold", fill: green)[Fonctionnalité 3 : Analyse temps réel et KPI]
|
||
|
||
*Description :* Module d'analyse des données en temps réel pour calculer et améliorer les indicateurs de performance clés (KPI) de la chaîne de production.
|
||
|
||
*Critères d'acceptation :*
|
||
- Calcul automatique des KPI (efficacité, disponibilité, qualité)
|
||
- Alertes configurables
|
||
- Détection d'anomalies en temps réel
|
||
- Dashboard de visualisation
|
||
- Historique des performances
|
||
|
||
*Priorité :* Moyenne
|
||
]
|
||
)
|
||
|
||
|
||
#rect(
|
||
width: 100%,
|
||
stroke: red + 1pt,
|
||
inset: 10pt,
|
||
radius: 5pt,
|
||
fill: red.lighten(95%),
|
||
[
|
||
#text(weight: "bold", fill: red)[Fonctionnalité 4 : Infrastructure téléopération]
|
||
|
||
*Description :* Préparation de l'architecture système pour permettre la téléopération future de la plateforme (contrôle à distance, maintenance prédictive).
|
||
|
||
*Critères d'acceptation :*
|
||
- Architecture modulaire et extensible
|
||
- Protocoles de communication sécurisés
|
||
- Interface de contrôle à distance (prototype)
|
||
- Documentation d'intégration
|
||
- Tests de latence et fiabilité
|
||
|
||
*Priorité :* Basse (Perspective future)
|
||
]
|
||
)
|
||
|
||
== Cas d'utilisation
|
||
|
||
=== Cas d'utilisation principaux
|
||
|
||
*CU1 : Supervision temps réel de la production*
|
||
- *Objectif :* Observer et analyser le fonctionnement de la chaîne de production
|
||
- *Préconditions :* Plateforme physique en fonctionnement, connexion établie
|
||
- *Scénario nominal :*
|
||
1. L'utilisateur se connecte au jumeau numérique
|
||
2. Il visualise la représentation 3D de la plateforme
|
||
3. Il observe les données capteurs en temps réel
|
||
4. Il analyse les KPI affichés sur le dashboard
|
||
5. Il identifie les anomalies ou optimisations possibles
|
||
- *Extensions :* Simulation de pannes, modification de paramètres
|
||
|
||
*CU2 : Analyse historique des données*
|
||
- *Objectif :* Analyser les tendances et performances passées
|
||
- *Préconditions :* Données historiques disponibles
|
||
- *Scénario nominal :*
|
||
1. L'utilisateur accède à l'interface d'analyse
|
||
2. Il sélectionne une période d'analyse
|
||
3. Il choisit les métriques à étudier
|
||
4. Il génère des graphiques et rapports
|
||
5. Il identifie des patterns et corrélations
|
||
- *Extensions :* Export de données, création de rapports personnalisés
|
||
|
||
*CU3 : Maintenance prédictive*
|
||
- *Objectif :* Anticiper les besoins de maintenance de la plateforme
|
||
- *Préconditions :* Modèles prédictifs configurés
|
||
- *Scénario nominal :*
|
||
1. Le système analyse les données capteurs
|
||
2. Il détecte des anomalies de fonctionnement
|
||
3. Il génère des alertes de maintenance
|
||
4. L'administrateur planifie les interventions
|
||
5. Il documente les actions correctives
|
||
- *Extensions :* Maintenance automatisée, historique des interventions
|
||
|
||
== Interface utilisateur
|
||
|
||
=== Principes de conception
|
||
|
||
*Approche centrée utilisateur :*
|
||
- Interface intuitive adaptée aux différents niveaux d'expertise
|
||
- Navigation claire et cohérente entre les modules
|
||
- Feedback visuel immédiat pour toutes les interactions
|
||
|
||
*Design responsive :*
|
||
- Adaptation automatique aux différentes tailles d'écran
|
||
- Support tablettes et écrans tactiles industriels
|
||
|
||
=== Interfaces principales
|
||
|
||
*Dashboard principal :*
|
||
- Vue d'ensemble temps réel de la plateforme de production
|
||
- Indicateurs KPI avec alertes visuelles (vert/orange/rouge)
|
||
- Graphiques interactifs des données capteurs
|
||
- Timeline des événements et anomalies
|
||
- Menu de navigation vers les modules spécialisés
|
||
|
||
*Interface d'analyse :*
|
||
- Outils de requête graphique pour l'exploration des données
|
||
- Générateur de graphiques
|
||
- Tableau de bord personnalisable par l'utilisateur
|
||
- Export facile vers formats standards (PDF, Excel, CSV)
|
||
- Système de favoris pour les analyses récurrentes
|
||
|
||
|
||
=== Exigences ergonomiques
|
||
|
||
*Navigation et organisation :*
|
||
- Menu principal persistant avec icônes explicites
|
||
- Fil d'Ariane pour situer l'utilisateur dans l'arborescence
|
||
- Raccourcis clavier pour les actions fréquentes
|
||
- Système d'onglets pour le multitâche
|
||
|
||
*Visualisation des données :*
|
||
- Choix de thèmes visuels (clair/sombre/contraste élevé)
|
||
- Codage couleur cohérent selon les standards industriels
|
||
- Graphiques interactifs avec zoom et filtrage
|
||
- Animation fluide des transitions d'état
|
||
- Gestion intelligente de la densité d'information
|
||
|
||
=== Exigences techniques UI/UX
|
||
|
||
*Compatibilité :*
|
||
- Support navigateurs modernes (Chrome, Firefox, Edge, Safari)
|
||
- Progressive Web App pour installation native
|
||
- API responsive pour intégration dans les systèmes préexistants
|
||
|
||
*Sécurité et authentification :*
|
||
- Sécurité et authentification conforme aux pratiques en vigueur sur les systèmes existants.
|
||
|
||
= Spécifications techniques
|
||
|
||
== Architecture système
|
||
L'architecture proposée suit un modèle en couches :
|
||
|
||
*Couche Physique :*
|
||
- Plateforme de démonstration avec capteurs et actionneurs
|
||
- Systèmes de contrôle (PLCs, contrôleurs industriels)
|
||
- Réseau industriel (Ethernet/IP, Profinet)
|
||
|
||
*Couche Communication :*
|
||
- Gateway OPC UA pour standardisation des protocoles
|
||
- Collecteur de données temps réel
|
||
- File d'attente de messages (MQTT/Redis)
|
||
|
||
*Couche Traitement :*
|
||
- Service d'agrégation et normalisation des données
|
||
- Moteur d'analyse temps réel et calcul des KPI
|
||
- Base de données temporelle pour l'historisation
|
||
|
||
*Couche Application :*
|
||
- API REST pour l'accès aux données
|
||
- Interface web pour visualisation et contrôle
|
||
|
||
*Couche Présentation :*
|
||
- Dashboard web interactif
|
||
|
||
== Technologies envisagées
|
||
- *Langages de programmation :* Python (backend), JavaScript/TypeScript (frontend), C++, C\#
|
||
- *Frameworks :*
|
||
- Backend : FastAPI, Flask, ou Django
|
||
- Frontend : React.js ou Vue.js pour les dashboards
|
||
- Communication : OPC UA, MQTT, WebSocket
|
||
- *Base de données :*
|
||
- Temporelle : InfluxDB ou TimescaleDB
|
||
- Relationnelle : PostgreSQL
|
||
- OLAP : ClickHouse, Apache Druid, Apache Pinot
|
||
- Cache : Redis
|
||
- *Outils de développement :* Docker, Git, CI/CD (GitLab/GitHub Actions)
|
||
- *Protocoles de communication :* OPC UA, Modbus TCP, Ethernet/IP
|
||
- *Formats d'échange :* JSON, XML, Protocol Buffers
|
||
|
||
== Intégrations
|
||
|
||
=== Intégration avec la plateforme physique DIWII
|
||
|
||
*Systèmes de contrôle industriel :*
|
||
- Connexion aux automates programmables (PLCs) via protocoles industriels
|
||
- Interface avec les systèmes existants
|
||
- Intégration des capteurs IoT (température, pression, position, vitesse)
|
||
- Synchronisation avec les actionneurs et variateurs de vitesse
|
||
|
||
*Protocoles de communication :*
|
||
- OPC UA pour l'interopérabilité standardisée
|
||
- Modbus TCP/IP pour les équipements legacy
|
||
- Ethernet/IP pour les composants Rockwell/Allen-Bradley
|
||
- MQTT pour les capteurs IoT et la télémetrie
|
||
|
||
=== Intégrations techniques
|
||
|
||
|
||
*Outils de développement :*
|
||
- Intégration continue avec GitLab CI/CD
|
||
- Monitoring avec Prometheus/Grafana
|
||
- Logging centralisé avec ELK Stack
|
||
- Tests automatisés avec Jenkins/GitHub Actions
|
||
|
||
*APIs :*
|
||
- API REST standardisée OpenAPI 3.0
|
||
- Gateway API pour la sécurité et le routage
|
||
|
||
=== Intégrations futures (perspective téléopération)
|
||
|
||
*Systèmes de contrôle avancés :*
|
||
- Interface avec systèmes de vision industrielle
|
||
- Intégration robotique collaborative (cobots)
|
||
- Systèmes de réalité augmentée pour la maintenance
|
||
- Jumeaux numériques de niveau entreprise (PLM/ERP)
|
||
|
||
|
||
= Contraintes et exigences
|
||
|
||
== Contraintes temporelles
|
||
|
||
- *Durée du projet :* 5 mois (Septembre 2025 - Janvier 2026)
|
||
- *Date de début :* 15 septembre 2025
|
||
- *Date de fin :* 31 janvier 2026
|
||
- *Soutenance prévue :* première semaine de février
|
||
|
||
=== Jalons importants
|
||
|
||
*Jalon 1 : 15 octobre 2025 - Analyse et conception terminées*
|
||
- Spécifications techniques détaillées validées
|
||
- Architecture système finalisée
|
||
- Environnement de développement configuré
|
||
- Première connexion à la plateforme DIWII établie
|
||
|
||
*Jalon 2 : 7 décembre 2025 - MVP (Minimum Viable Product) fonctionnel*
|
||
- Extraction de données capteurs opérationnelle
|
||
- Interface web de base déployée
|
||
- Premières métriques KPI calculées
|
||
- Tests d'intégration réussis
|
||
|
||
*Jalon 3 : 7 janvier 2025 - Version bêta complète*
|
||
- Toutes les fonctionnalités principales implémentées
|
||
- Interface utilisateur finalisée et testée
|
||
- Système d'analyse temps réel opérationnel
|
||
|
||
*Jalon 4 : 21 janvier 2026 - Finalisation et documentation*
|
||
- Correction des bugs critiques
|
||
- Documentation utilisateur complète
|
||
- Documentation technique rédigée
|
||
- Préparation de la présentation de soutenance
|
||
- Déploiement de la version finale
|
||
|
||
=== Contraintes critiques
|
||
|
||
*Ressources humaines :*
|
||
- Disponibilité de l'équipe de 3 étudiants
|
||
- Support technique de l'encadrant
|
||
- Accès aux experts techniques de DIWII
|
||
|
||
*Contraintes académiques :*
|
||
- Respect du calendrier
|
||
- Disponibilité des salles et équipements
|
||
|
||
*Risques temporels identifiés :*
|
||
- Complexité technique sous-estimée (probabilité moyenne)
|
||
- Problèmes d'accès à la plateforme physique (probabilité faible)
|
||
- Difficultés d'intégration des technologies (probabilité moyenne)
|
||
- Retard dans l’atteinte des jalons (probabilité élevée)
|
||
|
||
|
||
== Contraintes budgétaires
|
||
Pas de budget alloué pour ce projet étudiant. Toutes les ressources utilisées sont gratuites ou déjà disponibles via l'établissement ou DIWII.
|
||
|
||
== Contraintes réglementaires
|
||
Aucune contrainte réglementaire spécifique pour ce projet. Le développement et l'expérimentation se font dans le cadre académique et pédagogique.
|
||
|
||
== Contraintes de sécurité
|
||
Aucune contrainte de sécurité particulière au-delà des bonnes pratiques standards, incluant la gestion des accès, la confidentialité des données pédagogiques, le respect de la vie privée des utilisateurs ainsi que le respect des accords de confidentialité.
|
||
|
||
= Livrables
|
||
|
||
== Livrables techniques
|
||
- Code source commenté
|
||
- Tests unitaires et d'intégration
|
||
- Documentation technique
|
||
- Documentation utilisateur
|
||
- Guide d'installation
|
||
|
||
== Livrables académiques
|
||
- Présentation de soutenance |