Dans OUVRIFY, le contrôle qualité ne commence pas par une photo. Il commence par un objet chantier clairement identifié : projet, zone, Rack, Spool ou Work Item. Le terrain annonce que le travail est prêt. Le QC inspecte physiquement puis prend une décision. Cette séparation protège la traçabilité et évite qu’une exécution soit confondue avec une conformité.
Worker terminé ≠ QC validé
Un worker connaît l’état de son exécution. Il peut indiquer que son intervention est terminée, joindre une preuve ou signaler un blocage. Mais la conformité peut dépendre de critères, mesures, observations ou documents qu’un contrôleur doit vérifier séparément.
Le workflow de contrôle en cinq étapes
- Exécution : le worker réalise le travail affecté sur son scope.
- Soumission : le travail est déclaré prêt pour QC avec les preuves utiles.
- Inspection : le contrôleur consulte le contexte puis vérifie physiquement l’ouvrage.
- Décision : vérification, rejet ou demande de reprise selon le résultat.
- Historique : la décision et les reprises restent rattachées au même Work Item pour le reporting et l’audit.
Pourquoi le QC n’utilise pas l’APK Terrain
L’APK est destinée au Worker/Terrain. Le QC utilise le portail Web/PWA. Ce choix évite de mélanger les parcours et les permissions : l’outil du worker sert à exécuter et remonter l’information ; l’espace QC sert à examiner, décider et suivre les reprises.
Le portail QC peut recevoir des alertes lorsqu’un worker signale un blocage ou envoie un travail au contrôle. Les notifications système du navigateur sont un complément ; la file de contrôle et le centre de notifications Web restent les surfaces fonctionnelles principales.
Que doit voir un contrôleur ?
Le contrôleur ne doit pas recevoir des données provenant d’un autre projet ou d’un autre Rack simplement parce qu’il a accès au même tenant. Le scope fait partie de l’autorisation métier, pas seulement de l’affichage.
Rejet QC : conserver la raison, pas seulement le statut
Un statut « rejeté » isolé est peu utile. Il faut conserver la raison, l’observation et, lorsque pertinent, les preuves associées. La reprise doit ensuite rester reliée à cette décision afin de pouvoir répondre à trois questions : pourquoi le travail a-t-il été rejeté, qu’est-ce qui a été corrigé, et qui a validé après correction ?
| Événement | Donnée utile | Pourquoi la conserver |
|---|---|---|
| Soumission QC | Work Item, auteur, date, preuves | Savoir ce qui a réellement été présenté au contrôle. |
| Rejet | Motif, commentaire, contrôleur, date | Éviter une reprise sans contexte. |
| Reprise | Nouvelle exécution / preuve | Relier la correction au rejet initial. |
| Validation | Décision finale et audit | Identifier l’autorité qui a clôturé le contrôle. |
Blocages terrain et QC : ne pas tout mettre dans la même file
Un blocage signalé par le terrain peut nécessiter une intervention rapide du management ou du QC, mais il n’est pas nécessairement une soumission de conformité. OUVRIFY distingue les événements afin qu’un « WORK_BLOCKED » soit traité comme un blocage actif et qu’un « READY_FOR_QC » corresponde à un travail prêt pour inspection.
Cette séparation permet de donner des priorités différentes aux alertes et d’ouvrir directement le Work Item concerné.
Photos : preuve de contexte ou preuve de conformité ?
Une photo peut être indispensable. Elle peut montrer une situation avant correction, l’état après reprise ou un détail utile à l’inspection. Mais sa valeur dépend du processus. Une image seule ne dit pas automatiquement que tous les critères d’acceptation ont été respectés.
Le rapport doit donc distinguer les photos terrain des décisions QC et ne pas transformer la présence d’une image en validation implicite.
Comment le QC alimente le reporting
Une fois la décision enregistrée, le reporting peut séparer ce qui est exécuté de ce qui est vérifié. Cela évite de présenter au client un avancement qualité supérieur à la réalité. Les rapports peuvent inclure les décisions, reprises, observations et photos pertinentes sans modifier les données sources du chantier.
Voir aussi : reporting chantier basé sur une donnée vérifiée.
Permissions et sécurité du contrôle qualité
Un bouton caché n’est pas une permission. Les droits QC doivent être appliqués côté serveur, avec vérification de l’utilisateur, du tenant, du projet, du scope et des fonctions actives. Un worker ne doit pas pouvoir reproduire une requête réseau et s’attribuer un droit de validation simplement parce qu’il connaît l’API.
Les Sous-Managers peuvent recevoir des permissions plus fines, notamment sur la validation QC et le scope projet autorisé. Cette granularité doit rester cohérente entre l’interface et le backend.
Checklist d’un workflow QC robuste
- le travail est clairement identifié avant inspection ;
- le worker et le contrôleur ont des rôles distincts ;
- READY_FOR_QC n’est pas traité comme « conforme » ;
- le rejet comporte une raison exploitable ;
- la reprise reste reliée au rejet ;
- les décisions sont auditées ;
- les notifications ouvrent le bon Work Item ;
- les rapports n’utilisent comme « vérifié » que ce qui a réellement franchi l’étape QC.
Pour une trame opérationnelle distincte de ce guide de processus, consultez la checklist de contrôle qualité chantier au Maroc.
Questions fréquentes
Une photo peut-elle remplacer une inspection QC ?
Pas dans le modèle OUVRIFY lorsque le workflow exige une inspection physique. La photo apporte du contexte ; la décision appartient au contrôleur.
Le QC doit-il installer une APK ?
Non. Le QC travaille depuis le portail Web/PWA. L’APK est réservée au terrain.
Que se passe-t-il après un rejet ?
Le travail entre dans une logique de reprise. Le motif du rejet et les éléments associés restent disponibles afin que la correction puisse être contrôlée à nouveau.
Réserves et corrections chantier · PV de réception chantier au Maroc.
Une donnée terrain qui reste exploitable jusqu’au rapport
OUVRIFY relie exécution, contrôle qualité, ressources, coûts et reporting sans transformer le chantier en ERP généraliste.
Demander une démonstration