Pawrise CareComment l'équipe découpe, organise et planifie le travail : structure de découpage (WBS), organisation (OBS), responsabilités (RACI), méthodologie, plan qualité et planning sur 20 mois.
WBS · Work Breakdown Structure
9 lots techniques, du collier à la conformité. Cliquez pour déplier.
OBS · Organisation
10 personnes réparties en 5 pôles de 2, sous le pilotage du Product Owner.
Fullstack
2Backend & portail : API, ingestion, base de données, authentification, Vet Portal
IoT
2Collier : firmware, capteurs, simulateur, prototype matériel
Design / Mobile
2App : UX/UI, app mobile, identité visuelle, étude de marché
IA / Data
2Care Engine : RAG, POCs, pipeline de données
Cloud / Ops
2Infra : cloud, CI/CD, monitoring, sécurité
Chaque pôle compte deux personnes, le Product Owner assurant la coordination transverse. Yassine cumule le rôle de Product Owner et de contributeur IA/Data. Elarif est rattaché au pôle Design/Mobile, en binôme avec Adam sur l'application, mais intervient en transverse sur le Backend, l'IoT, la CI/CD, le marché et le lien vétérinaire. Le détail des responsabilités nominatives par domaine, avec backups, est précisé dans la table de couverture ci-dessous.
Couverture nominative · qui fait quoi
Chaque domaine est porté par un ou plusieurs responsables nommés, avec un backup identifié pour assurer la continuité (adéquation ressource / tâche).
| Domaine | Responsable(s) | Backup |
|---|---|---|
| Product Ownership | Yassine | Elarif (transverse, vision produit) |
| IoT / Hardware | Cyril, Ibrahim | Hamid, Elarif (support embarqué) |
| Backend / API | Hamid, Aaditya, Elarif | Yassine |
| IA / Data | Nino, Yassine | Hamid (pipelines Python) |
| Mobile / Frontend | Adam, Elarif | Oumar (Android), Hamid, Aaditya |
| Design / UX | Adam | Elarif (intégration front) |
| Market / Business | Adam, Elarif | Yassine (PO) |
| Cloud / DevOps | Oumar, Abderrahmane | Elarif (CI/CD) |
| Réseau vétérinaire | Elarif, Nino | Binôme (2 contacts vété distincts) |
RACI · Responsabilités par activité
Qui est responsable, approbateur, consulté ou informé pour chaque activité (par pôle).
| Activité | Pilotage (PO) | Fullstack | IoT | Design/Mobile | IA/Data | Cloud/Ops |
|---|---|---|---|---|---|---|
| Cadrage & spécifications | A/R | C | C | C | C | C |
| API & ingestion données | C | A/R | C | I | C | C |
| Collier & firmware | C | C | A/R | I | C | I |
| Application mobile | C | R | I | A/R | C | I |
| Moteur IA / Care Engine | C | C | I | C | A/R | I |
| Portail vétérinaire | C | A/R | I | C | C | I |
| Infra / CI-CD / monitoring | I | C | I | I | I | A/R |
| RGPD & sécurité données | A | R | C | I | C | C |
| Tests & qualité | A | R | R | R | R | R |
Version standard : exactement un garant (A) par activité et au moins un responsable (R), C et I libres. Le A est distribué : chaque pôle est garant de son propre livrable, le Product Owner reste garant du cadrage et de la gouvernance (RGPD, qualité). A/R signale un pôle à la fois responsable et garant. C'est la lecture conforme au standard RACI.
Les 6 pôles recoupent l'organisation (OBS) ci-dessus : Fullstack (backend & portail), IoT (collier), Design/Mobile (app), IA/Data (Care Engine), Cloud/Ops (infra). La RACI arbitre au niveau des pôles, l'échelon de responsabilité ; la responsabilité individuelle, tâche par tâche, est portée par l'assignation nominative des tickets Jira (10/10 membres) et par la couverture nominative par domaine.
Planning & Roadmap
Décembre 2025 → Juillet 2027 : conception, développement parallèle, intégration.
- 1Juil 2026Keynote
- 2Sep 2026Infra op.
- 3Nov 2026Simulateur
- 4Jan 2027Backend complet
- 5Avr 2027MVP intégré
- 6Mai 2027Portail Véto
- 7Juil 2027Fin projet
Pourquoi tout démarre en parallèle ?
Le parallélisme n'est pas un pari : les 5 pôles avancent en parallèle dès juillet et aucun epic n'attend qu'un autre soit terminé. Chacun démarre par sa part non bloquante (design, maquettes / mocks, simulateur, machinerie) et ne consolide qu'une fois sa dépendance réelle disponible. Le Vet Portal (E7) est le seul epic vraiment dépendant (backend + IA) : échafaudage sur mocks dès novembre 2026, câblage aux vraies sorties IA en février 2027. E8 et E10 sont post-MVP : différés par priorité, pas par blocage technique.
Dépendances clés
- E11 Plateforme (socle)→Tous les epicstout se déploie sur l'infrastructure, construite en premier puis exploitée en continu
- E2 Collecte (simulateur)→E3, E4, E5, E6la donnée alimente tout : features et IA démarrent sur données simulées, sans attendre le collier
- Baseline de données→E5 Anomaliesdétecter une anomalie exige plusieurs mois d'historique par animal (démarrage à froid)
- E6 IA + E2 données→E7 Vet Portalle portail affiche les résumés et alertes issus de l'IA
Préparer tous les livrables pour la keynote.
- Cadrage : WBS, OBS, RACI, SWOT, PESTEL, AMDEC, Risk MapToute l'équipe
- Organisation : méthodologie, Quality Plan, outilsYassine
- Technique : benchmarks, architecture, specsPôles tech
- Marché : étude, positionnement, personasAdam, Elarif
- POCs : simulateur collier, RAG / Chat IANino, Yassine, Cyril
Développer tous les composants en parallèle.
- Infrastructure : Cloud, CI/CD, monitoringOumar, Abderrahmane · Juil → Sept 2026
- Backend : API, BDD, Auth, IngestionHamid, Aaditya, Elarif · Juil 2026 → Jan 2027
- Collier IoT : simulateur puis hardwareCyril, Ibrahim · Juil 2026 → Avr 2027
- App Mobile : Auth, Dashboard, GPS, Chat IAAdam, Elarif · Juil 2026 → Mai 2027
- Moteur IA + Data : POCs puis intégrationNino, Yassine · Juil 2026 → Avr 2027
- Portail Véto : dashboard, escalade, rapportsHamid, Aaditya, Elarif · Fév → Mai 2027
Assembler, tester, stabiliser.
- Tests E2E : tous les composants connectésToute l'équipe · Mai 2027
- Beta interne : tests utilisateursToute l'équipe · Mai → Juin 2027
- Documentation : doc technique, guide utilisateurToute l'équipe · Juil 2027
Risques planning & mitigations
| Risque | Impact | Mitigation |
|---|---|---|
| Retard de la keynote | Bloque le démarrage de la phase de développement | Prioriser les livrables réellement évalués |
| Hardware complexe | Retard du collier IoT | Simulateur en fallback : le reste n'attend pas le matériel |
| RAG plus long que prévu | Retard du moteur IA | Lancer les POCs très tôt (dès la phase de conception) |
| Intégration tardive | Bugs découverts trop tard | Tests continus tout au long, pas seulement à la fin |
Outil de gestion · Jira
Le projet est piloté sur un board Jira (projet SCRUM) adopté par les 10 membres : backlog, sprints, estimation en story points et assignation nominative des tâches. Confluence héberge la documentation, GitHub le code et les PR.
Flux de travail (board)
Board Jira (projet SCRUM) sur pawrise.atlassian.net : backlog priorisé, sprints, et tâches assignées nominativement aux 10 membres.
Estimation · story points (Planning Poker)
Les tickets Jira sont estimés en story points (effort global : complexité, volume, incertitude, dépendances), pas en heures. L'estimation se fait en équipe par Planning Poker pour aligner la compréhension.
Au-delà de 13 points, le ticket est découpé. Les points restent stables pendant le sprint.
Méthodologie · Scrum adapté
Le choix méthodologique, sa justification et la cadence de l'équipe.
Pawrise Care adopte une méthodologie Scrum adaptée : agilité itérative et incrémentale, tenant compte des contraintes académiques de l'équipe (10 personnes, projet sur 20 mois).
Rôles : Product Owner (Yassine) · Scrum Master tournant · Équipe de développement (pôles)
Outils : Jira (backlog, sprints, estimation story points) · Confluence (docs) · GitHub (code, PR, CI) · Figma (design).
Pourquoi Scrum adapté (agile itératif) ?
Le périmètre évolue avec les apprentissages (POCs IA, faisabilité hardware, retours du vétérinaire partenaire) : on ne peut pas tout figer en amont. Scrum permet de livrer par incréments, de réorienter à chaque sprint et d'absorber l'incertitude technique sans replanifier tout le projet.
Suppose un cahier des charges figé en amont. Incompatible avec l'incertitude R&D (IA, capteurs) et les retours terrain itératifs.
Excellent pour un flux continu, mais sans cadence ni engagement de sprint il offre peu de prévisibilité pour une équipe de 10 et une soutenance jalonnée. On en retient le tableau visuel et la limite de WIP.
« Adapté » car l'équipe est étudiante : Scrum Master tournant (montée en compétence de tous), sprints alignés sur le calendrier académique, et un PO unique garant de la priorisation.
Plan qualité
Stratégie de tests par couche, conventions de code, workflow Git, CI/CD et onboarding, pour faciliter l'intégration de nouveaux développeurs.
Stratégie de tests par couche
Tests unitaires et fonctionnels obligatoires ; E2E / smoke sur les flux critiques. La Definition of Done d'une User Story inclut obligatoirement ses tests et sa couverture. Les tests automatisés s'exécutent à chaque Pull Request via la CI (merge bloqué si rouge).
| Couche | Outils | Cible |
|---|---|---|
| Firmware collier (C / Zephyr) | tests unitaires (Zephyr) + analyse statique (Clang-Tidy, Cppcheck, MISRA C) + simulateur de capteurs | Logique de collecte/encodage validée hors matériel ; sûreté mémoire par MISRA C + allocation statique. |
| Services backend (Rust) | tests unitaires (cargo nextest) + intégration API sur services réels (testcontainers) | Logique métier et endpoints couverts ; tests d'abus obligatoires sur l'auth. |
| Moteur IA / Care Engine (Python) | pytest + jeux d'évaluation RAG + garde-fous anti-diagnostic | Non-régression des réponses et déclenchement systématique de l'escalade en cas de doute. |
| App mobile (Kotlin / SwiftUI) | tests unitaires natifs + tests d'UI critiques | Parcours d'onboarding, appairage et alertes vérifiés. |
| Bout en bout (E2E / smoke) | scénarios end-to-end sur les flux critiques (phase d'intégration) | Collier → backend → IA → app/portail validés ensemble. |
| Performance / charge | tests de charge (k6 / Locust) sur les endpoints critiques | Temps de réponse p95 et montée en charge validés avant la production (NFR6, NFR7). |
Règle d'or produit : l'IA n'émet jamais de diagnostic. Les tests du Care Engine vérifient que toute situation ambiguë déclenche une orientation ou une escalade vers le vétérinaire, jamais une conclusion médicale.
Definition of Done
Conditions qu'une User Story doit toutes remplir pour être considérée comme terminée.
- Les critères d'acceptation de la User Story (Given/When/Then) sont tous satisfaits.
- Le code est relu et approuvé par au moins un pair via une Pull Request.
- Les tests de la story sont écrits et passent : unitaires et fonctionnels obligatoires (intégration et E2E si flux critique).
- La couverture de code atteint le seuil fixé (mesurée en CI, merge bloqué sinon).
- La CI est verte : format, lint, tests et audit automatiques réussis (le merge est bloqué sinon).
- La documentation utile est à jour (README du service, doc d'API, Confluence si besoin).
- Aucune régression : un bug corrigé est couvert par un test de non-régression.
Conventions de code
- Linting/formatage automatiques par langage : rustfmt + clippy (Rust), ruff/black (Python), ktlint (Kotlin), ESLint + Prettier (TS/Next).
- Nommage cohérent par langage (snake_case Rust/Python, camelCase Kotlin/TS) et noms descriptifs.
- Toute fonctionnalité passe par une Pull Request relue par au moins un pair avant merge.
- Pas de secret en clair dans le code : variables d'environnement + secrets chiffrés (SOPS).
Workflow Git
Règles Git officielles du projet : travail collaboratif structuré, traçabilité complète et livraisons fiables. Branche stable protégée, le travail se fait sur des branches dédiées fusionnées par Pull Request relue.
- main : Branche stable et déployable. Protégée : merge uniquement via PR validée.
- develop : Intégration continue des fonctionnalités avant stabilisation.
- feat/<scope> : Une fonctionnalité = une branche, rattachée à un ticket Jira (ex. feat/SCRUM-42-appairage).
- fix/<scope> : Correction de bug isolée et traçable.
Commits : Messages de commit conventionnels (feat:, fix:, docs:, chore:…) référençant la clé du ticket Jira pour la traçabilité.
Pull Request : Chaque PR : description claire, lien Jira, CI verte (lint + tests) et revue d'au moins un pair avant merge.
CI/CD & déploiement
- CI centrée Cargo (quasi full-Rust), tout gate bloquant : cargo fmt --check, cargo sort --check, cargo clippy -- -D warnings, cargo machete.
- Tests + couverture : cargo llvm-cov nextest --fail-under-lines 80 (objectif 90 % sur le code critique) ; intégration via testcontainers.
- Sécurité & supply chain : cargo audit (RustSec) à chaque PR, Dependabot hebdomadaire groupé (Cargo, GitHub Actions, mobile).
- Déploiement GitOps : images Docker versionnées, Helm + Argo CD ; environnements develop → staging → production, canal hotfix dédié.
- Secrets chiffrés (SOPS + age) ; observabilité OpenTelemetry → Prometheus/Loki/Tempo → Grafana ; rollback par revert Git.
Onboarding développeur
- Accès : dépôt GitHub, projet Jira (SCRUM) et espace Confluence (PC) donnés dès l'arrivée.
- Lecture d'entrée : ce plan qualité, le Git Workflow et l'architecture globale (cockpit).
- Mise en route locale : clone du repo, installation des dépendances, lancement en local (README de chaque service).
- Première contribution : prendre un ticket « bonne première tâche » dans Jira, ouvrir une PR en suivant les conventions.