3d-interface-rapport/rapport/conclusion.tex

\part*{Remerciements}
Je tiens particulièrement à remercier \\

\begin{itemize}
    \item Vicent \textsc{Charvillat}, pour m'avoir donné l'occasion de faire un
        stage intéressant, et pour toute l'aide qu'il a pu me fournir
    \item Geraldine \textsc{Morin}, pour sa disponibilité
    \item Axel \textsc{Carlier}, pour son aide et ses conseils sur les points
        plus techniques
    \item Wei Tsang \textsc{Ooi}, pour ses suggestions souvent pertinentes
\end{itemize}

\paragraph{}
mais je me dois aussi de remercier \\

\begin{itemize}
    \item Thierry \textsc{Malon} et Émilie \textsc{Jalras}, pour avoir joué le
        rôle de canard en plastique \footnote{\emph{La méthode du canard en
        plastique consiste à expliquer méticuleusement le code source que l'on
        a écrit à un collègue, à un simple passant, ou même à un objet inanimé
        comme un canard en plastique. Le simple fait d'exprimer ses pensées à
        voix haute est censé aider à trouver les erreurs de programmation.
        Comme les réactions de l'interlocuteur ou son niveau de compréhension
        du problème n'ont aucune importance dans ce processus, on peut le
        remplacer par un canard en plastique.} --- Contenu soumis à la licence
        CC-BY-SA 3.0 (\url{http://creativecommons.org/licenses/by-sa/3.0/deed.fr})
        Source : Article Méthode du canard en plastique de Wikipédia en
        français
        (\url{http://fr.wikipedia.org/wiki/M\%C3\%A9thode\_du\_canard\_en\_plastique})}.
        et plus encore,
    \item Julien \textsc{Fayer}, qui nous a accompagné durant les derniers mois
        de nos stages
    \item Bastien \textsc{Durix},
    \item Vincent \textsc{Angladon},
    \item David \textsc{Courtinot}, qui m'a fourni un soutien psychologique
        lorsque JavaScript était méchant avec moi
\end{itemize}

\newpage
\part*{Conclusion}

\paragraph{}
En conclusion, pendant ce stage, nous avons tenté de développé une interface
permettant à des utilisateurs non-expérimentés de parcourir des scènes 3D. Ce
système peut s'ouvrir sur d'autres problématiques : nous pourrions par exemple
utiliser ce genre de recommandation 3D sur des systèmes qui représentent des
scènes grâce à des images 2D (comme Google Maps par exemple).

\paragraph{}
Une autre optique qui pourrait être utile à la suite de ce projet est de
générer les recommandations automatiquement à partir d'interactions
d'utilisateurs. On pourrait penser à un algorithme qui détecte les zones que
les utilisateurs aiment regarder, et placer une recommandation à cet endroit
pour les futurs utilisateurs.

\paragraph{}
\paragraph{}
Peu avant ce stage, nous avons eu le projet long qui nous a permis
d'expérimenter les projets d'envergure en groupe, et la façon dont on devait
les gérer.

\paragraph{}
Ce stage, pendant lequel j'ai développé le programme (\emph{plus ou moins})
seul m'a permis de compléter les expériences que j'avais eu lors du projet
long.  En effet, la plupart des projets étudiants à l'ENSEEIHT sont de très
petite taille (si l'on devait passer 35h par semaine sur ces projets, je crois
qu'il n'y en aurait pas un qui durerait plus de trois jours), et on ne se rend
en fait pas compte que certaines des techniques de gestion de projet que nous
avons dû mettre en application pendant le projet long sont tout aussi
importantes dans le cas d'un projet seul.

\paragraph{}
Dès nos premiers cours à l'ENSEEIHT, on nous enseignait l'importance des
commentaires qui rendaient compréhensible un programme à quelqu'un d'autre, ou
parfois, à soi-même mais dans le futur. Mais sur un projet de quelques jours,
il est évident que l'on comprendra toujours ce qu'on a fait avant. Cependant
dès que le projet devient suffisament important, on se rend compte qu'il est
impossible de maîtriser parfaitement le code d'un bout à l'autre, et que c'est
là que les commentaires prennent tout leur sens.

\paragraph{}
Ce projet a été très agréable pour moi, puisqu'il m'a permis de me consacrer à
temps plein, et pendant une longue durée, à un programme qui part de zéro.
Lors d'un projet en groupe, ou d'un sous-projet qui permet de constituer une
brique d'un plus gros bâtiment, on peut ressentir la fierté d'avoir participé à
un si grand projet, mais il y a aussi cette sensation qu'au final, l'impact que
l'on a eu sur ce projet n'est pas si grande que ça. Lors d'un projet fait seul
(ou en petite équipe), et qui part de zéro, on voit le programme grandir au fur
et à mesure, ses fonctionnalités s'améliorer, ses bugs se corriger et de
nouveaux apparaître, et regarder le projet une fois terminé est nettement plus
flatteur pour l'ego.