Étudiants en informatique en RDC collaborant sur un projet de développement logiciel.

Projet-3

Réalisation supervisée d'une application informatique complexe.

Édition 2026 – Réforme LMD – Enseignement supérieur et universitaire en RDC.

  • Code Officiel : PIA1363
  • Domaine : Sciences et Technologie
  • Filière : Sciences Informatiques
  • Mention : Intelligence Artificielle
  • Année d’étude : Licence 3
  • Semestre : Semestre 6
Consulter les Modalités, Compétences et Débouchés

Cette Unité d’Enseignement, valorisée à hauteur de 6 crédits ECTS, est entièrement structurée autour d’un unique Élément Constitutif : le Projet-3. Cette approche monobloc et immersive est conçue pour plonger les étudiants au cœur d’une expérience de développement concrète, où la théorie s’efface au profit de la mise en pratique intensive, simulant les conditions réelles d’un cycle de production logiciel complet.

L’objectif est de transformer les étudiants en praticiens agiles et compétents, capables d’intégrer des algorithmes avancés pour construire une application informatique performante et intelligente. Parallèlement, l’accent sera mis sur les piliers du travail collaboratif moderne, notamment une gestion de version rigoureuse et la production d’une documentation du code source claire, garantissant la pérennité du projet. Enfin, la compétence à tester la robustesse du logiciel face à des jeux de données réels assurera que les solutions développées sont non seulement fonctionnelles, mais aussi fiables et prêtes pour le déploiement.

Cette UE prépare directement à des métiers clés pour la transformation numérique en République Démocratique du Congo. Le Développeur d’applications est l’artisan qui bâtit les outils digitaux essentiels à la modernisation des entreprises. Le Chargé de projet R&D junior joue un rôle d’innovateur, transformant les idées en produits viables qui stimulent la compétitivité locale. Enfin, le Testeur de logiciels est le garant de la qualité et de la confiance, un rôle crucial sur un marché de l’emploi en RDC où la fiabilité des solutions numériques est un facteur déterminant de succès.

SOMMAIRE NAVIGABLE

PRÉLIMINAIRES

I. Épistémologie et Enjeux Scientifiques du Domaine

La conception logicielle a muté d’un artisanat solitaire vers une ingénierie collaborative et systémique. L’intégration de l’intelligence artificielle n’est plus une spécialité de niche mais le cœur réacteur des applications modernes, transformant la donnée brute en service prédictif. Cet enseignement acte cette transition fondamentale en positionnant le “projet” non comme un simple exercice, mais comme le creuset où fusionnent l’architecture logicielle, la science des données et la gestion de produit. L’enjeu est de former des praticiens capables de piloter cette complexité, de la modélisation algorithmique à la mise en production robuste.

II. Cartographie des Compétences et Transversalité

Les trois compétences visées – intégrer des algorithmes, gérer le code en équipe et tester la robustesse – forment un triptyque indissociable du développeur moderne. Loin d’être des silos techniques, elles s’interpénètrent continuellement : l’intégration d’un modèle IA (compétence 1) impose une rigueur de versioning (compétence 2) et des stratégies de test spécifiques (compétence 3). Cette UE établit des ponts directs avec la gestion de projet (méthodes Agiles), l’ingénierie des systèmes (architectures microservices) et l’éthique de l’IA, armant l’étudiant d’une vision holistique qui transcende la simple écriture de code.

III. Alignement Stratégique avec les Réalités Opérationnelles

Face aux besoins du marché congolais et africain, la capacité à livrer rapidement des applications fiables et intelligentes est un avantage compétitif absolu. Les métiers de développeur, de chargé de projet R&D et de testeur convergent vers un profil unique de “problem solver” technologique. Ce cours est calibré pour répondre à cette demande en simulant un cycle de développement complet, de l’idéation à la maintenance. L’objectif est de rendre l’étudiant immédiatement opérationnel, capable de rejoindre une startup ou une ESN et de contribuer à des projets concrets dans la fintech, l’agritech ou la e-santé.

Chapitre I. Fondations du Projet Logiciel : Méthodologie et Environnement de Développement

I.1 Définition du Cadre Méthodologique Agile

Née de la rigidité des cycles en V, la pensée Agile a imposé dès 2001 une rupture philosophique majeure dans la conduite de projet. Ce sous-chapitre déconstruit les dogmes pour en extraire l’essence pragmatique : la livraison itérative de valeur et l’adaptation continue face à l’incertitude, des principes vitaux pour les écosystèmes technologiques émergents où les cahiers des charges sont volatiles. L’étudiant apprendra à structurer un projet non pas par un plan rigide, mais par un carnet de produit (backlog) dynamique et priorisé, garantissant l’alignement constant avec le besoin utilisateur.

I.2 Configuration de l’Environnement de Développement Unifié

La standardisation de l’environnement de travail est le prérequis non négociable de toute collaboration efficace. Ce segment se concentre sur la mise en place d’un poste de développement reproductible et isolé, en s’appuyant sur des outils comme Visual Studio Code et ses extensions, ainsi que sur les conteneurs Docker pour encapsuler les dépendances. L’objectif est de neutraliser le syndrome du “ça marche sur ma machine”. L’apprenant maîtrisera la création d’un Dockerfile de base pour son application, assurant une portabilité parfaite entre les membres de l’équipe et les serveurs de production.

I.3 Analyse Critique des Outils de Gestion de Projet

Sous l’angle de la frugalité, le choix d’un outil de gestion de projet (Jira, Trello, Asana) n’est pas neutre et peut induire une complexité contre-productive. Cette section analyse de manière critique le rapport coût/bénéfice de ces plateformes, en particulier pour les petites équipes aux ressources limitées. Nous y questionnons la pertinence d’une usine à gaz logicielle face à des solutions plus légères, voire des tableaux Kanban physiques, lorsque la co-localisation le permet. L’étudiant développera un esprit critique pour sélectionner l’outil strictement nécessaire à son contexte, évitant la surcharge cognitive.

I.4 Mise en Situation : Cadrage d’un Projet à Impact Local

Face aux défis de l’urbanisation de Kinshasa, la gestion des déchets constitue une problématique concrète. Cet exercice pratique impose à l’étudiant de définir le périmètre d’une application mobile simple visant à cartographier les points de collecte et à notifier les services de ramassage. En utilisant la méthode des “user stories”, il devra rédiger un premier backlog, estimer la complexité des tâches et définir un Produit Minimum Viable (MVP). Cette application directe ancre la méthodologie dans une réalité socio-économique tangible, prouvant l’utilité immédiate de la compétence.

Chapitre II. Architecture Applicative et Intégration d’API d’Intelligence Artificielle

II.1 Principes d’Architecture : Monolithe vs. Microservices

Le débat architectural entre monolithe et microservices structure la conception logicielle contemporaine. Le monolithe, unifié et simple à déployer initialement, s’oppose à la flexibilité et la résilience des microservices, qui décomposent l’application en services indépendants et spécialisés. Ce sous-chapitre expose la physique de chaque approche, leurs implications en termes de communication inter-services (API REST, gRPC) et de complexité opérationnelle. L’étudiant saisira les arbitrages fondamentaux à réaliser en amont d’un projet pour garantir sa scalabilité et sa maintenabilité futures, particulièrement pour intégrer des composants IA.

II.2 Conception d’Interfaces de Programmation (API) RESTful

Une API RESTful constitue le système nerveux d’une application moderne, permettant aux différents composants de communiquer de manière standardisée. En se basant sur les verbes HTTP (GET, POST, PUT, DELETE) et une structuration logique des ressources, elle expose les fonctionnalités du backend, notamment les modèles d’IA. Ce segment enseigne la conception rigoureuse d’une API, de la définition des routes à la structuration des réponses JSON et à la gestion des codes de statut. L’étudiant saura modéliser et documenter une API propre, découplée et prête à être consommée.

II.3 Limites et Vulnérabilités des API Publiques

Exposer une fonctionnalité via une API crée une surface d’attaque qui doit être impérativement maîtrisée. Cette section aborde les failles de sécurité critiques listées par l’OWASP API Security Top 10, telles que l’authentification brisée, l’exposition excessive de données ou la mauvaise gestion des ressources. L’analyse se porte sur les mécanismes de défense : tokens (JWT), limitation de débit (rate limiting) et validation systématique des entrées. L’apprenant intégrera une paranoïa constructive dans sa conception, considérant chaque point d’accès comme une potentielle porte d’entrée pour une attaque.

II.4 Application : Intégration d’un Service de Traduction Automatique

Pour une application de e-commerce visant le marché de la SADC, la barrière de la langue est un frein majeur. L’exercice consiste à intégrer une API d’IA externe (comme Google Translate ou des alternatives open-source) pour traduire dynamiquement les descriptions de produits. L’étudiant devra gérer les clés d’API de manière sécurisée, construire les requêtes HTTP, traiter les réponses asynchrones et gérer les erreurs (service indisponible, quotas dépassés). Ce cas pratique solidifie la compétence d’intégration d’un service intelligent tiers dans une application existante.

Chapitre III. Implémentation d’Algorithmes de Machine Learning : Du Modèle à la Production

III.1 Le Cycle de Vie d’un Modèle de Machine Learning

La création d’un modèle prédictif suit un processus industriel rigoureux, bien au-delà de l’écriture d’un script. Ce cycle de vie, de la collecte et du nettoyage des données à l’entraînement, l’évaluation, le déploiement et le monitoring, forme la colonne vertébrale de la MLOps. Ce sous-chapitre formalise chaque étape, en insistant sur l’importance de la reproductibilité des expériences et de la validation croisée pour éviter le surapprentissage. L’étudiant comprendra qu’un modèle n’est pas un artefact statique mais un système dynamique qui doit être maintenu et ré-entraîné.

III.2 Outillage : Utilisation de Scikit-Learn et TensorFlow Lite

D’origine académique, la bibliothèque Scikit-Learn est devenue le standard de facto pour le machine learning classique, tandis que TensorFlow Lite s’impose pour l’inférence sur des appareils à ressources limitées comme les smartphones. Ce segment est un guide pratique pour l’utilisation de ces outils : charger un jeu de données, choisir un algorithme (régression, classification), l’entraîner avec la méthode .fit() et évaluer sa performance. L’étudiant apprendra à sauvegarder un modèle entraîné et à le convertir au format TFLite, le préparant pour son intégration mobile.

III.3 Analyse Critique : Biais Algorithmiques et Problème de la “Boîte Noire”

La performance d’un modèle d’IA ne garantit en rien sa justesse éthique ou son explicabilité. Cette section plonge au cœur de la controverse des biais algorithmiques, démontrant comment des données d’entraînement non représentatives peuvent conduire à des décisions discriminatoires, un risque majeur pour des applications en finance ou en santé. Nous y abordons également le défi de la “boîte noire” des réseaux de neurones profonds et les premières techniques d’interprétabilité (SHAP, LIME). L’étudiant sera sensibilisé à sa responsabilité de développeur face à l’impact sociétal de ses créations.

III.4 Mise en Situation : Intégration d’un Modèle de Détection de Maladie de Plante

Dans le contexte agricole congolais, l’identification précoce des maladies du manioc est cruciale. L’étudiant recevra un modèle de classification d’images pré-entraîné (format .h5 ou .tflite). Sa mission sera de l’intégrer dans une application web simple (utilisant Flask ou FastAPI) qui expose un point d’accès (endpoint) où un utilisateur peut envoyer une photo de feuille de manioc. L’application doit retourner la prédiction de la maladie, démontrant la chaîne complète de l’intégration d’un algorithme avancé dans un service concret et utile.

Chapitre IV. Gestion de Code Source et Collaboration d’Équipe : Le Paradigme Git

IV.1 Fondements du Contrôle de Version Distribué avec Git

Conceptualisé par Linus Torvalds en 2005 pour gérer le noyau Linux, Git a révolutionné la collaboration en instaurant un modèle distribué. Chaque développeur possède une copie complète de l’historique, permettant un travail hors-ligne et une résilience accrue du projet. Ce sous-chapitre dissèque la structure de Git : le “commit” comme un instantané atomique, les branches comme des univers parallèles de développement et le “merge” comme leur point de réconciliation. L’étudiant assimilera la philosophie derrière l’outil, essentielle pour l’utiliser avec maîtrise plutôt que par mimétisme.

IV.2 Maîtrise des Commandes Essentielles et du Workflow de Branches

La pratique de Git repose sur un ensemble de commandes fondamentales qui orchestrent le flux de travail. Ce segment technique se concentre sur le cycle add, commit, push et pull, puis explore les stratégies de branches (branching models) comme GitFlow ou GitHub Flow pour organiser le développement de nouvelles fonctionnalités et la correction de bugs. L’accent est mis sur la rédaction de messages de commit clairs et la gestion des “pull requests” (ou “merge requests”). L’étudiant saura manipuler l’historique de son projet de manière propre et professionnelle.

IV.3 Gestion des Conflits de Fusion et Discipline d’Équipe

Le conflit de fusion (“merge conflict”) est une conséquence inévitable du travail parallèle et non un signe d’échec. Cette section démystifie ce processus en le présentant comme une négociation technique qui requiert communication et méthode. Elle fournit une procédure systématique pour identifier les lignes conflictuelles, comprendre les modifications concurrentes et résoudre le conflit de manière sécurisée. L’analyse porte aussi sur la discipline d’équipe nécessaire pour minimiser ces conflits, comme la communication fréquente et les petites validations (commits) régulières, évitant les divergences massives.

IV.4 Simulation : Collaboration sur un Dépôt Partagé (GitHub/GitLab)

Pour simuler un environnement professionnel, les étudiants travailleront en binômes sur un dépôt distant hébergé sur GitHub ou une instance locale de GitLab. Le scénario impose la création d’une fonctionnalité simple pour une application de micro-finance : un étudiant développera le backend (API), l’autre le frontend (interface). Ils devront utiliser un workflow de branches, créer des “pull requests” pour la revue de code par leur pair et gérer au moins un conflit de fusion provoqué. Cet exercice ancre la compétence de collaboration dans un flux de travail réaliste.

Chapitre V. Stratégies de Test et Validation : Assurer la Robustesse Applicative

V.1 La Pyramide des Tests : Unitaire, Intégration, et de Bout-en-Bout (E2E)

Introduite par Mike Cohn, la pyramide des tests est un modèle stratégique pour allouer les efforts de test de manière efficace. Elle préconise une large base de tests unitaires rapides et peu coûteux, une couche intermédiaire de tests d’intégration vérifiant l’interaction entre les composants, et un sommet étroit de tests de bout-en-bout (E2E) qui simulent le parcours utilisateur complet. Ce sous-chapitre détaille le rôle, le périmètre et le coût de chaque type de test. L’étudiant apprendra à penser la qualité logicielle comme une construction structurée et non une vérification monolithique.

V.2 Outillage Pratique : Écriture de Tests avec Pytest et Jest

La théorie du test s’incarne dans des frameworks concrets qui automatisent la vérification du code. Pour le backend Python, Pytest s’est imposé par sa simplicité et sa puissance, tandis que Jest domine l’écosystème JavaScript/Frontend. Ce segment est un atelier pratique : écrire un premier test unitaire pour une fonction pure, utiliser les “mocks” pour isoler les dépendances externes (comme une base de données ou une API), et structurer les fichiers de test. L’étudiant acquerra le réflexe d’écrire le test en même temps que le code de la fonctionnalité.

V.3 Analyse Critique : La Métrique de Couverture de Code et ses Limites

La couverture de code (code coverage) est une métrique séduisante qui mesure le pourcentage de lignes de code exécutées par la suite de tests. Cependant, un score de 100% ne garantit en rien l’absence de bugs et peut devenir un objectif vaniteux s’il n’est pas corrélé à la qualité des assertions. Cette section critique l’obsession de la métrique en montrant qu’un test peut “couvrir” une ligne sans en vérifier la logique. L’étudiant apprendra à interpréter ce chiffre avec prudence, en se concentrant sur la pertinence des scénarios testés.

V.4 Application : Tester la Robustesse face à des Données Réelles Africaines

Les applications déployées en Afrique font face à des conditions uniques : connectivité intermittente, formats de numéros de téléphone variés, noms propres complexes. Cet exercice consiste à écrire des tests pour une fonction d’inscription utilisateur qui doit gérer ces cas de figure. L’étudiant devra créer des jeux de données de test simulant des entrées malformées, des coupures réseau (en “mockant” l’API), et des cas limites spécifiques au contexte local. L’objectif est de forger une mentalité de test défensif, anticipant les défaillances du monde réel.

Chapitre VI. Déploiement, Maintenance et Optimisation en Contexte de Contraintes

VI.1 Fondements de l’Intégration et du Déploiement Continus (CI/CD)

L’automatisation du cycle de vie logiciel via des pipelines CI/CD est la clé pour livrer des améliorations de manière rapide et fiable. L’intégration continue (CI) automatise la compilation et les tests à chaque modification du code, tandis que le déploiement continu (CD) automatise la mise en production du code validé. Ce sous-chapitre explique la logique de ces pipelines en utilisant des outils comme GitHub Actions ou GitLab CI. L’étudiant comprendra comment cette automatisation réduit drastiquement le risque d’erreur humaine et accélère la boucle de feedback avec les utilisateurs.

VI.2 Conteneurisation avec Docker pour un Déploiement Isolé

Docker a résolu le problème de la portabilité des applications en les encapsulant, avec toutes leurs dépendances, dans des conteneurs légers et isolés. Ce segment technique se concentre sur la finalisation du Dockerfile pour la production : optimisation de la taille de l’image, gestion des secrets (clés d’API, mots de passe) et configuration des variables d’environnement. L’étudiant apprendra à construire une image Docker de son application, prête à être exécutée de manière identique sur son poste, sur le serveur d’un collègue ou dans le cloud.

VI.3 Critique des Plateformes Cloud et Valorisation de l’Innovation Frugale

Sous la pression marketing, les plateformes cloud comme AWS ou Azure sont souvent présentées comme l’unique solution de déploiement viable. Cette section offre une analyse critique de leur modèle économique, de leur complexité et de leur dépendance à une connectivité internet stable, des freins potentiels pour de nombreux projets en RDC. En contrepoint, elle valorise l’innovation frugale : le déploiement sur des serveurs privés virtuels (VPS) à bas coût, sur des machines physiques locales, voire sur des nano-ordinateurs comme le Raspberry Pi pour des services à faible charge.

VI.4 Mise en Production : Déploiement d’une Application sur un Serveur Distant

L’ultime étape du projet consiste à rendre l’application accessible sur Internet. Dans cet exercice final, l’étudiant déploiera l’application conteneurisée développée tout au long du semestre sur un petit serveur VPS Linux. Il devra configurer un serveur web inverse (reverse proxy) comme Nginx pour exposer l’application, gérer les logs pour le monitoring et, si possible, sécuriser la connexion avec un certificat SSL Let’s Encrypt. Cette mise en situation concrétise l’ensemble des compétences acquises, transformant un projet local en un service potentiellement global.

ANNEXES

A. Guide Pratique de Git et GitHub

Cet outil est la pierre angulaire du développeur d’applications moderne. Ce guide ne se contente pas de lister des commandes ; il formalise un protocole de travail collaboratif pour le chargé de projet R&D junior, lui permettant de structurer les contributions d’une équipe, de mener des revues de code rigoureuses via les “pull requests” et de maintenir un historique de projet propre et auditable. Pour le développeur, c’est l’assurance de pouvoir expérimenter sans risque, de revenir en arrière et de fusionner son travail avec celui des autres de manière contrôlée.

B. Mémento de Commandes Docker

Pour le développeur d’applications et le chargé de projet R&D, Docker est un levier de productivité majeur. Il garantit que l’environnement de développement est une réplique exacte de l’environnement de production, éliminant une classe entière de bugs liés à la configuration. Cette annexe fournit les commandes essentielles pour construire une image, lancer un conteneur, gérer les volumes de données persistantes et orchestrer plusieurs services avec Docker Compose. C’est un outil stratégique pour accélérer l’intégration de nouveaux développeurs et simplifier radicalement les déploiements.

C. Utilisation de Postman pour le Test d’API

Postman est le couteau suisse du testeur de logiciels et du développeur backend. Il permet de forger et d’envoyer des requêtes HTTP complexes à une API sans écrire une seule ligne de code, afin d’en valider le comportement, la performance et la sécurité. Cette annexe montre comment créer des collections de requêtes pour automatiser les tests de régression, utiliser des variables d’environnement pour basculer entre les serveurs de test et de production, et écrire des scripts de test simples en JavaScript pour valider les réponses. C’est un outil indispensable pour garantir la qualité d’une architecture microservices.

De la Théorie à la Praxis : Enjeux Opérationnels et Stratégies d’Adaptation en RDC
Comment concilier les approches participatives, prônées par les bailleurs, avec les structures de pouvoir traditionnelles très hiérarchisées ?
Le paradoxe se résout en mobilisant l’approche par les capacités d’Amartya Sen. Plutôt que d’imposer un modèle participatif occidental, qui peut être perçu comme une menace par les détenteurs du pouvoir coutumier, l’objectif devient d’élargir les ‘capabilités’ réelles des individus. Cela signifie se concentrer sur l’amélioration de l’éducation, de la santé et de l’accès à l’information pour que les membres de la communauté, femmes et jeunes inclus, puissent choisir librement de participer et de faire entendre leur voix de manière éclairée. L’enjeu n’est plus la forme de la participation, mais la liberté substantielle de l’exercer, respectant ainsi les dynamiques locales tout en promouvant l’émancipation individuelle.

📚 Source :Travaux de Amartya Sen sur l’approche par les capacités via Cairn.info

Face à une connectivité internet erratique en brousse, comment assurer la remontée fiable des données de suivi de projet ?
La solution réside dans l’application du concept de ‘technologie appropriée’ d’E.F. Schumacher. Plutôt que de dépendre de solutions high-tech fragiles, il faut privilégier des outils robustes et adaptés au contexte. Concrètement, cela implique l’utilisation d’applications mobiles de collecte de données fonctionnant hors ligne, comme KoboToolbox ou ODK. Les équipes de terrain peuvent ainsi enregistrer les informations toute la journée sans connexion. La synchronisation des données s’effectue ensuite de manière planifiée et ponctuelle, lors du passage dans une zone avec un signal stable. Cette approche ‘low-tech, high-impact’ garantit la résilience et la fiabilité du système de suivi-évaluation.

📚 Source :Travaux de E.F. Schumacher sur la technologie appropriée via Google Books

Une milice locale bloque subitement l’accès à votre chantier à Walikale. Comment négocier une reprise sécurisée des activités ?
L’urgence commande de dépasser la confrontation directe en appliquant la ‘négociation raisonnée’ de William Ury. L’objectif est de passer des positions (notre droit de passage contre leur blocus) aux intérêts sous-jacents (sécurité, reconnaissance, bénéfices économiques). La première étape est d’identifier et d’engager un médiateur crédible, un ‘troisième côté’ comme un chef coutumier respecté ou un leader religieux influent, qui n’est pas directement partie au conflit. Cette médiation permet d’ouvrir un canal de dialogue sécurisé pour comprendre les griefs de la milice et co-construire une solution mutuellement acceptable, transformant un jeu à somme nulle en opportunité.

📚 Source :Travaux de William Ury sur la négociation raisonnée via JSTOR

Au-delà des indicateurs de performance, comment évaluer l’impact réel et durable d’un projet de développement sur le long terme ?
Les cadres logiques rigides sont insuffisants. Pour saisir l’impact réel, il faut adopter ‘l’évaluation développementale’ de Michael Quinn Patton. Cette approche intègre l’évaluateur au sein de l’équipe projet, non pas comme un juge externe, mais comme un facilitateur stratégique. Son rôle est de fournir des retours en temps réel pour aider le projet à s’adapter et à innover face à une réalité complexe. L’accent est mis sur l’apprentissage continu et la compréhension des dynamiques émergentes plutôt que sur la mesure d’indicateurs prédéfinis. Cela permet de naviguer l’incertitude et de maximiser la pertinence et la durabilité de l’intervention.

📚 Source :Travaux de Michael Quinn Patton sur l’évaluation développementale via Google Scholar


Discussion (0)

Aucune intervention pour le moment. Soyez le premier à contribuer.

Votre intervention Annuler la réponse

Leave a Reply

Your email address will not be published. Required fields are marked *