1
00:00:00,940 --> 00:00:04,420
Dossiers et démarches est une application
née à partir d'un prototype assez simple

2
00:00:04,440 --> 00:00:06,440
que j'avais commencé pour une association.

3
00:00:07,100 --> 00:00:09,080
Le projet ne s'est
finalement pas poursuivi

4
00:00:09,100 --> 00:00:12,671
faute de financement de leur côté, donc
j'ai repris et élargi le prototype.

5
00:00:13,360 --> 00:00:15,800
Pour l'instant, le parcours
fonctionne autour de demandes liées

6
00:00:15,820 --> 00:00:19,740
aux métiers du transport. Chauffeur
de taxi, chauffeur logisticien, etc.

7
00:00:20,420 --> 00:00:23,400
Mais l'idée serait de pouvoir
l'adapter à d'autres démarches.

8
00:00:23,700 --> 00:00:25,000
Le concept.

9
00:00:26,940 --> 00:00:30,660
Le concept de base est simple.
Un usager crée son compte

10
00:00:30,680 --> 00:00:34,580
et constitue son dossier en ligne avec
les informations et les pièces demandées.

11
00:00:34,900 --> 00:00:38,580
Une fois envoyé, le dossier est récupéré
par un agent qui va l'instruire.

12
00:00:39,140 --> 00:00:41,040
Si par exemple il manque quelque chose,

13
00:00:41,300 --> 00:00:44,633
l'agent peut demander une correction
précise et spécifique à l'usager.

14
00:00:44,740 --> 00:00:48,360
Une fois le dossier prêt, il propose
une décision qui doit ensuite

15
00:00:48,380 --> 00:00:52,360
être contrôlée par un superviseur
avant d'être réellement validée.

16
00:00:53,660 --> 00:00:56,000
Présenté tel quel, le parcours
semble assez simple,

17
00:00:56,020 --> 00:00:58,080
mais il y avait plusieurs problèmes

18
00:00:58,100 --> 00:01:00,400
auxquels je voulais
vraiment faire attention.

19
00:01:01,220 --> 00:01:03,780
Le premier point, c'est
la sécurité des fichiers.

20
00:01:04,340 --> 00:01:07,120
Je ne voulais pas qu'un document
soit considéré comme fiable

21
00:01:07,140 --> 00:01:09,900
simplement parce qu'un
utilisateur l'a envoyé.

22
00:01:10,300 --> 00:01:13,740
J'ai donc fait en sorte que les fichiers
passent d'abord par une quarantaine

23
00:01:13,760 --> 00:01:16,100
avec des contrôles de format et de taille,

24
00:01:16,160 --> 00:01:20,400
puis une analyse antivirus avant
de pouvoir être consultés par les agents.

25
00:01:21,000 --> 00:01:24,940
Toutes les pièces, nouvelles
ou remplacées, passent par ces contrôles.

26
00:01:26,140 --> 00:01:28,740
Un autre point que je
voulais aussi éviter,

27
00:01:28,780 --> 00:01:31,923
c'est qu'une demande de correction
rouvre complètement le dossier.

28
00:01:32,280 --> 00:01:36,042
Si un agent demande uniquement de modifier
l'adresse et de remplacer une pièce,

29
00:01:36,200 --> 00:01:40,400
l'usager ne peut modifier que ces
éléments-là. Tout le reste est verrouillé.

30
00:01:41,120 --> 00:01:45,220
Et ce n'est pas seulement l'interface
qui désactive des champs, le serveur

31
00:01:45,240 --> 00:01:48,940
vérifie aussi que les modifications
restent bien dans le périmètre demandé.

32
00:01:49,640 --> 00:01:52,021
L'autre grosse partie sur
laquelle j'ai travaillé,

33
00:01:52,140 --> 00:01:54,160
c'est le cloisonnement des données
et des responsabilités.

34
00:01:54,180 --> 00:01:57,100
L'application distingue sept rôles :

35
00:01:57,240 --> 00:01:59,350
l'usager qui gère ses propres dossiers,

36
00:01:59,540 --> 00:02:02,826
l'agent qui instruit les dossiers
auxquels il est autorisé à accéder,

37
00:02:03,480 --> 00:02:07,147
le superviseur qui contrôle notamment
les décisions proposées par les agents,

38
00:02:07,720 --> 00:02:10,940
l'administrateur fonctionnel
qui gère plutôt l'organisation

39
00:02:10,960 --> 00:02:12,800
et les comptes autorisés,

40
00:02:13,120 --> 00:02:16,100
l'administrateur technique qui s'occupe
du fonctionnement de la plateforme

41
00:02:16,120 --> 00:02:19,680
mais dont le rôle ne donne pas
accès aux pièces des usagers,

42
00:02:20,400 --> 00:02:24,600
l'auditeur de sécurité qui peut consulter
les traces et contrôler certaines actions,

43
00:02:25,040 --> 00:02:27,560
et enfin le propriétaire
de la démonstration

44
00:02:27,580 --> 00:02:30,980
dont le rôle est principalement
d'initialiser et d'administrer

45
00:02:31,000 --> 00:02:33,381
l'environnement de démonstration
de l'application.

46
00:02:36,180 --> 00:02:39,800
L'idée derrière tout ça ce n'était pas
d'avoir sept rôles juste pour avoir

47
00:02:39,820 --> 00:02:43,300
sept rôles, c'était surtout d'éviter
qu'un seul compte puisse tout faire

48
00:02:43,320 --> 00:02:47,100
et tout voir et de limiter les dégâts
si un compte est compromis.

49
00:02:47,880 --> 00:02:51,380
Et là encore ce n'est pas simplement
l'interface qui masque des boutons,

50
00:02:51,420 --> 00:02:53,840
les autorisations sont vérifiées côté API.

51
00:02:54,400 --> 00:02:56,700
Même lorsqu'un agent a
le droit d'ouvrir une pièce,

52
00:02:56,760 --> 00:02:58,600
il doit indiquer pourquoi il la consulte

53
00:02:58,620 --> 00:03:01,900
et cette consultation est
journalisée avec son auteur.

54
00:03:02,440 --> 00:03:04,780
Les notes internes
suivent la même logique.

55
00:03:05,140 --> 00:03:07,807
Elles ne sont pas juste cachées
visuellement à l'usager,

56
00:03:08,160 --> 00:03:11,060
elles ne lui sont pas envoyées
par l'API tout simplement.

57
00:03:12,460 --> 00:03:16,000
Les comptes professionnels utilisent
aussi la double authentification

58
00:03:16,020 --> 00:03:19,640
et les actions sensibles sont
journalisées pour l'audit.

59
00:03:20,860 --> 00:03:23,580
Pour la décision finale
appliquée à un dossier,

60
00:03:24,080 --> 00:03:26,160
j'ai appliqué un principe assez simple.

61
00:03:26,800 --> 00:03:30,760
La personne qui propose une décision
ne peut pas la valider elle-même.

62
00:03:31,300 --> 00:03:33,800
L'agent peut proposer d'accepter
ou de refuser un dossier,

63
00:03:33,820 --> 00:03:37,500
mais il faut qu'un superviseur distinct
contrôle ensuite cette décision.

64
00:03:37,720 --> 00:03:39,840
Ça évite qu'un même compte
puisse à la fois proposer

65
00:03:39,860 --> 00:03:42,200
et confirmer la décision sur un dossier.

66
00:03:46,460 --> 00:03:49,480
Pour la stack, j'utilise
React et TypeScript,

67
00:03:49,520 --> 00:03:52,720
côté front-end, FastAPI
avec Python pour l'API,

68
00:03:53,020 --> 00:03:56,600
PostgreSQL pour les données
et Docker pour les environnements.

69
00:03:57,140 --> 00:04:01,140
Pour tout ce qui est analyse antivirus
des fichiers, j'utilise ClamAV.

70
00:04:01,960 --> 00:04:04,140
Je teste aussi certains cas de panne.

71
00:04:04,640 --> 00:04:07,980
Si l'antivirus ne répond plus,
par exemple, le fichier doit rester

72
00:04:08,000 --> 00:04:11,720
bloqué plutôt que de devenir
accessible sans avoir été contrôlé.

73
00:04:12,640 --> 00:04:16,740
Les tests backend vérifient directement
ces règles et les scénarios Chromium

74
00:04:16,760 --> 00:04:19,480
rejouent ensuite les principaux
parcours depuis le navigateur

75
00:04:19,500 --> 00:04:21,800
avec les différents comptes.

76
00:04:22,100 --> 00:04:24,220
Au final, Dossiers et démarches ressemble

77
00:04:24,240 --> 00:04:27,500
assez simplement à une application
de dépôt et de traitement de dossier.

78
00:04:27,600 --> 00:04:30,400
Le vrai travail, c'était surtout
de contrôler les documents,

79
00:04:30,420 --> 00:04:33,480
limiter les corrections,
séparer les accès et éviter

80
00:04:33,500 --> 00:04:36,452
qu'un même compte puisse proposer
puis confirmer une décision.

81
00:04:36,700 --> 00:04:38,500
Ça reste évidemment
une démonstration de portfolio

82
00:04:38,520 --> 00:04:41,300
avec uniquement des comptes
et des documents fictifs,

83
00:04:41,320 --> 00:04:43,980
mais l'objectif est de construire
un workflow de bout en bout

84
00:04:44,000 --> 00:04:47,500
et pas simplement un formulaire
connecté à une base de données.