diff --git a/docs/_static/img/graphs/activity.svg b/docs/_static/img/graphs/activity.svg
new file mode 100644
index 00000000..22971f1e
--- /dev/null
+++ b/docs/_static/img/graphs/activity.svg
@@ -0,0 +1,344 @@
+
+
+
+
+
+
+model_graph
+
+activity_models_ActivityType
+
+ ActivityType
+
+id
+
+
+AutoField
+
+
+can_invite
+
+
+BooleanField
+
+
+guest_entry_fee
+
+
+PositiveIntegerField
+
+
+manage_entries
+
+
+BooleanField
+
+
+name
+
+
+CharField
+
+
+
+
+activity_models_Activity
+
+ Activity
+
+id
+
+
+AutoField
+
+
+activity_type
+
+
+ForeignKey (id)
+
+
+attendees_club
+
+
+ForeignKey (id)
+
+
+creater
+
+
+ForeignKey (id)
+
+
+organizer
+
+
+ForeignKey (id)
+
+
+date_end
+
+
+DateTimeField
+
+
+date_start
+
+
+DateTimeField
+
+
+description
+
+
+TextField
+
+
+location
+
+
+CharField
+
+
+name
+
+
+CharField
+
+
+open
+
+
+BooleanField
+
+
+valid
+
+
+BooleanField
+
+
+
+
+activity_models_Activity->activity_models_ActivityType
+ activity_type (+)
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+activity_models_Activity->django_contrib_auth_models_User
+ creater (activity)
+
+
+
+member_models_Club
+
+Club
+
+
+
+
+activity_models_Activity->member_models_Club
+ organizer (+)
+
+
+
+activity_models_Activity->member_models_Club
+ attendees_club (+)
+
+
+
+activity_models_Entry
+
+ Entry
+
+id
+
+
+AutoField
+
+
+activity
+
+
+ForeignKey (id)
+
+
+guest
+
+
+OneToOneField (id)
+
+
+note
+
+
+ForeignKey (note_ptr)
+
+
+time
+
+
+DateTimeField
+
+
+
+
+activity_models_Entry->activity_models_Activity
+ activity (entries)
+
+
+
+activity_models_Guest
+
+ Guest
+
+id
+
+
+AutoField
+
+
+activity
+
+
+ForeignKey (id)
+
+
+inviter
+
+
+ForeignKey (note_ptr)
+
+
+first_name
+
+
+CharField
+
+
+last_name
+
+
+CharField
+
+
+
+
+activity_models_Entry->activity_models_Guest
+ guest (entry)
+
+
+
+note_models_notes_NoteUser
+
+NoteUser
+
+
+
+
+activity_models_Entry->note_models_notes_NoteUser
+ note (entry)
+
+
+
+activity_models_Guest->activity_models_Activity
+ activity (+)
+
+
+
+activity_models_Guest->note_models_notes_NoteUser
+ inviter (guests)
+
+
+
+activity_models_GuestTransaction
+
+ GuestTransaction
+
+transaction_ptr
+
+
+OneToOneField (id)
+
+
+entry
+
+
+OneToOneField (id)
+
+
+
+
+activity_models_GuestTransaction->activity_models_Entry
+ entry (guesttransaction)
+
+
+
+note_models_transactions_Transaction
+
+Transaction
+
+
+
+
+activity_models_GuestTransaction->note_models_transactions_Transaction
+ multi-table
+inheritance
+
+
+
diff --git a/docs/_static/img/graphs/logs.svg b/docs/_static/img/graphs/logs.svg
new file mode 100644
index 00000000..e451eda4
--- /dev/null
+++ b/docs/_static/img/graphs/logs.svg
@@ -0,0 +1,108 @@
+
+
+
+
+
+
+model_graph
+
+logs_models_Changelog
+
+ Changelog
+
+id
+
+
+AutoField
+
+
+model
+
+
+ForeignKey (id)
+
+
+user
+
+
+ForeignKey (id)
+
+
+action
+
+
+CharField
+
+
+data
+
+
+TextField
+
+
+instance_pk
+
+
+CharField
+
+
+ip
+
+
+GenericIPAddressField
+
+
+previous
+
+
+TextField
+
+
+timestamp
+
+
+DateTimeField
+
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+logs_models_Changelog->django_contrib_auth_models_User
+ user (changelog)
+
+
+
+django_contrib_contenttypes_models_ContentType
+
+ContentType
+
+
+
+
+logs_models_Changelog->django_contrib_contenttypes_models_ContentType
+ model (changelog)
+
+
+
diff --git a/docs/_static/img/graphs/member.svg b/docs/_static/img/graphs/member.svg
new file mode 100644
index 00000000..9057b40c
--- /dev/null
+++ b/docs/_static/img/graphs/member.svg
@@ -0,0 +1,279 @@
+
+
+
+
+
+
+model_graph
+
+member_models_Profile
+
+ Profile
+
+id
+
+
+AutoField
+
+
+user
+
+
+OneToOneField (id)
+
+
+address
+
+
+CharField
+
+
+department
+
+
+CharField
+
+
+email_confirmed
+
+
+BooleanField
+
+
+last_report
+
+
+DateTimeField
+
+
+ml_art_registration
+
+
+BooleanField
+
+
+ml_events_registration
+
+
+CharField
+
+
+ml_sport_registration
+
+
+BooleanField
+
+
+paid
+
+
+BooleanField
+
+
+phone_number
+
+
+PhoneNumberField
+
+
+promotion
+
+
+PositiveSmallIntegerField
+
+
+registration_valid
+
+
+BooleanField
+
+
+report_frequency
+
+
+PositiveSmallIntegerField
+
+
+section
+
+
+CharField
+
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+member_models_Profile->django_contrib_auth_models_User
+ user (profile)
+
+
+
+member_models_Club
+
+ Club
+
+id
+
+
+AutoField
+
+
+parent_club
+
+
+ForeignKey (id)
+
+
+email
+
+
+EmailField
+
+
+membership_duration
+
+
+PositiveIntegerField
+
+
+membership_end
+
+
+DateField
+
+
+membership_fee_paid
+
+
+PositiveIntegerField
+
+
+membership_fee_unpaid
+
+
+PositiveIntegerField
+
+
+membership_start
+
+
+DateField
+
+
+name
+
+
+CharField
+
+
+require_memberships
+
+
+BooleanField
+
+
+
+
+member_models_Club->member_models_Club
+ parent_club (club)
+
+
+
+member_models_Membership
+
+ Membership
+
+id
+
+
+AutoField
+
+
+club
+
+
+ForeignKey (id)
+
+
+user
+
+
+ForeignKey (id)
+
+
+date_end
+
+
+DateField
+
+
+date_start
+
+
+DateField
+
+
+fee
+
+
+PositiveIntegerField
+
+
+
+
+member_models_Membership->member_models_Club
+ club (membership)
+
+
+
+member_models_Membership->django_contrib_auth_models_User
+ user (memberships)
+
+
+
+permission_models_Role
+
+Role
+
+
+
+
+member_models_Membership->permission_models_Role
+ roles (membership)
+
+
+
diff --git a/docs/_static/img/graphs/note.svg b/docs/_static/img/graphs/note.svg
new file mode 100644
index 00000000..ac066243
--- /dev/null
+++ b/docs/_static/img/graphs/note.svg
@@ -0,0 +1,588 @@
+
+
+
+
+
+
+model_graph
+
+polymorphic_models_PolymorphicModel
+
+ PolymorphicModel
+
+polymorphic_ctype
+
+
+ForeignKey (id)
+
+
+
+
+django_contrib_contenttypes_models_ContentType
+
+ContentType
+
+
+
+
+polymorphic_models_PolymorphicModel->django_contrib_contenttypes_models_ContentType
+ polymorphic_ctype (polymorphic_%(app_label)s.%(class)s_set+)
+
+
+
+note_models_notes_Note
+
+ Note
+<
+PolymorphicModel
+>
+
+id
+
+
+AutoField
+
+
+polymorphic_ctype
+
+
+ForeignKey (id)
+
+
+balance
+
+
+BigIntegerField
+
+
+created_at
+
+
+DateTimeField
+
+
+display_image
+
+
+ImageField
+
+
+inactivity_reason
+
+
+CharField
+
+
+is_active
+
+
+BooleanField
+
+
+last_negative
+
+
+DateTimeField
+
+
+
+
+note_models_notes_Note->polymorphic_models_PolymorphicModel
+ abstract
+inheritance
+
+
+
+note_models_notes_NoteUser
+
+ NoteUser
+
+note_ptr
+
+
+OneToOneField (id)
+
+
+user
+
+
+OneToOneField (id)
+
+
+
+
+note_models_notes_NoteUser->note_models_notes_Note
+ multi-table
+inheritance
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+note_models_notes_NoteUser->django_contrib_auth_models_User
+ user (note)
+
+
+
+note_models_notes_NoteClub
+
+ NoteClub
+
+note_ptr
+
+
+OneToOneField (id)
+
+
+club
+
+
+OneToOneField (id)
+
+
+
+
+note_models_notes_NoteClub->note_models_notes_Note
+ multi-table
+inheritance
+
+
+
+member_models_Club
+
+Club
+
+
+
+
+note_models_notes_NoteClub->member_models_Club
+ club (note)
+
+
+
+note_models_notes_NoteSpecial
+
+ NoteSpecial
+
+note_ptr
+
+
+OneToOneField (id)
+
+
+special_type
+
+
+CharField
+
+
+
+
+note_models_notes_NoteSpecial->note_models_notes_Note
+ multi-table
+inheritance
+
+
+
+note_models_notes_Alias
+
+ Alias
+
+id
+
+
+AutoField
+
+
+note
+
+
+ForeignKey (id)
+
+
+name
+
+
+CharField
+
+
+normalized_name
+
+
+CharField
+
+
+
+
+note_models_notes_Alias->note_models_notes_Note
+ note (alias)
+
+
+
+note_models_transactions_TemplateCategory
+
+ TemplateCategory
+
+id
+
+
+AutoField
+
+
+name
+
+
+CharField
+
+
+
+
+note_models_transactions_TransactionTemplate
+
+ TransactionTemplate
+
+id
+
+
+AutoField
+
+
+category
+
+
+ForeignKey (id)
+
+
+destination
+
+
+ForeignKey (note_ptr)
+
+
+amount
+
+
+PositiveIntegerField
+
+
+description
+
+
+CharField
+
+
+display
+
+
+BooleanField
+
+
+highlighted
+
+
+BooleanField
+
+
+name
+
+
+CharField
+
+
+
+
+note_models_transactions_TransactionTemplate->note_models_notes_NoteClub
+ destination (+)
+
+
+
+note_models_transactions_TransactionTemplate->note_models_transactions_TemplateCategory
+ category (templates)
+
+
+
+note_models_transactions_Transaction
+
+ Transaction
+<
+PolymorphicModel
+>
+
+id
+
+
+AutoField
+
+
+destination
+
+
+ForeignKey (id)
+
+
+polymorphic_ctype
+
+
+ForeignKey (id)
+
+
+source
+
+
+ForeignKey (id)
+
+
+amount
+
+
+PositiveIntegerField
+
+
+created_at
+
+
+DateTimeField
+
+
+destination_alias
+
+
+CharField
+
+
+invalidity_reason
+
+
+CharField
+
+
+quantity
+
+
+PositiveIntegerField
+
+
+reason
+
+
+CharField
+
+
+source_alias
+
+
+CharField
+
+
+valid
+
+
+BooleanField
+
+
+
+
+note_models_transactions_Transaction->polymorphic_models_PolymorphicModel
+ abstract
+inheritance
+
+
+
+note_models_transactions_Transaction->note_models_notes_Note
+ source (+)
+
+
+
+note_models_transactions_Transaction->note_models_notes_Note
+ destination (+)
+
+
+
+note_models_transactions_RecurrentTransaction
+
+ RecurrentTransaction
+
+transaction_ptr
+
+
+OneToOneField (id)
+
+
+template
+
+
+ForeignKey (id)
+
+
+
+
+note_models_transactions_RecurrentTransaction->note_models_transactions_TransactionTemplate
+ template (recurrenttransaction)
+
+
+
+note_models_transactions_RecurrentTransaction->note_models_transactions_Transaction
+ multi-table
+inheritance
+
+
+
+note_models_transactions_SpecialTransaction
+
+ SpecialTransaction
+
+transaction_ptr
+
+
+OneToOneField (id)
+
+
+bank
+
+
+CharField
+
+
+first_name
+
+
+CharField
+
+
+last_name
+
+
+CharField
+
+
+
+
+note_models_transactions_SpecialTransaction->note_models_transactions_Transaction
+ multi-table
+inheritance
+
+
+
+note_models_transactions_MembershipTransaction
+
+ MembershipTransaction
+
+transaction_ptr
+
+
+OneToOneField (id)
+
+
+membership
+
+
+OneToOneField (id)
+
+
+
+
+note_models_transactions_MembershipTransaction->note_models_transactions_Transaction
+ multi-table
+inheritance
+
+
+
+member_models_Membership
+
+Membership
+
+
+
+
+note_models_transactions_MembershipTransaction->member_models_Membership
+ membership (transaction)
+
+
+
diff --git a/docs/_static/img/graphs/permission.svg b/docs/_static/img/graphs/permission.svg
new file mode 100644
index 00000000..e7fd7350
--- /dev/null
+++ b/docs/_static/img/graphs/permission.svg
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+model_graph
+
+permission_models_PermissionMask
+
+ PermissionMask
+
+id
+
+
+AutoField
+
+
+description
+
+
+CharField
+
+
+rank
+
+
+PositiveSmallIntegerField
+
+
+
+
+permission_models_Permission
+
+ Permission
+
+id
+
+
+AutoField
+
+
+mask
+
+
+ForeignKey (id)
+
+
+model
+
+
+ForeignKey (id)
+
+
+description
+
+
+CharField
+
+
+field
+
+
+CharField
+
+
+permanent
+
+
+BooleanField
+
+
+query
+
+
+TextField
+
+
+type
+
+
+CharField
+
+
+
+
+permission_models_Permission->permission_models_PermissionMask
+ mask (permissions)
+
+
+
+django_contrib_contenttypes_models_ContentType
+
+ContentType
+
+
+
+
+permission_models_Permission->django_contrib_contenttypes_models_ContentType
+ model (+)
+
+
+
+permission_models_Role
+
+ Role
+
+id
+
+
+AutoField
+
+
+for_club
+
+
+ForeignKey (id)
+
+
+name
+
+
+CharField
+
+
+
+
+permission_models_Role->permission_models_Permission
+ permissions (role)
+
+
+
+member_models_Club
+
+Club
+
+
+
+
+permission_models_Role->member_models_Club
+ for_club (role)
+
+
+
diff --git a/docs/_static/img/graphs/treasury.svg b/docs/_static/img/graphs/treasury.svg
new file mode 100644
index 00000000..c2fca750
--- /dev/null
+++ b/docs/_static/img/graphs/treasury.svg
@@ -0,0 +1,324 @@
+
+
+
+
+
+
+model_graph
+
+treasury_models_Invoice
+
+ Invoice
+
+id
+
+
+PositiveIntegerField
+
+
+acquitted
+
+
+BooleanField
+
+
+address
+
+
+TextField
+
+
+bde
+
+
+CharField
+
+
+date
+
+
+DateField
+
+
+description
+
+
+TextField
+
+
+locked
+
+
+BooleanField
+
+
+name
+
+
+CharField
+
+
+object
+
+
+CharField
+
+
+tex
+
+
+TextField
+
+
+
+
+treasury_models_Product
+
+ Product
+
+id
+
+
+AutoField
+
+
+invoice
+
+
+ForeignKey (id)
+
+
+amount
+
+
+IntegerField
+
+
+designation
+
+
+CharField
+
+
+quantity
+
+
+PositiveIntegerField
+
+
+
+
+treasury_models_Product->treasury_models_Invoice
+ invoice (products)
+
+
+
+treasury_models_RemittanceType
+
+ RemittanceType
+
+id
+
+
+AutoField
+
+
+note
+
+
+OneToOneField (note_ptr)
+
+
+
+
+note_models_notes_NoteSpecial
+
+NoteSpecial
+
+
+
+
+treasury_models_RemittanceType->note_models_notes_NoteSpecial
+ note (remittancetype)
+
+
+
+treasury_models_Remittance
+
+ Remittance
+
+id
+
+
+AutoField
+
+
+remittance_type
+
+
+ForeignKey (id)
+
+
+closed
+
+
+BooleanField
+
+
+comment
+
+
+CharField
+
+
+date
+
+
+DateTimeField
+
+
+
+
+treasury_models_Remittance->treasury_models_RemittanceType
+ remittance_type (remittance)
+
+
+
+treasury_models_SpecialTransactionProxy
+
+ SpecialTransactionProxy
+
+id
+
+
+AutoField
+
+
+remittance
+
+
+ForeignKey (id)
+
+
+transaction
+
+
+OneToOneField (transaction_ptr)
+
+
+
+
+treasury_models_SpecialTransactionProxy->treasury_models_Remittance
+ remittance (specialtransactionproxy)
+
+
+
+note_models_transactions_SpecialTransaction
+
+SpecialTransaction
+
+
+
+
+treasury_models_SpecialTransactionProxy->note_models_transactions_SpecialTransaction
+ transaction (specialtransactionproxy)
+
+
+
+treasury_models_SogeCredit
+
+ SogeCredit
+
+id
+
+
+AutoField
+
+
+credit_transaction
+
+
+OneToOneField (transaction_ptr)
+
+
+user
+
+
+OneToOneField (id)
+
+
+
+
+treasury_models_SogeCredit->note_models_transactions_SpecialTransaction
+ credit_transaction (sogecredit)
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+treasury_models_SogeCredit->django_contrib_auth_models_User
+ user (sogecredit)
+
+
+
+note_models_transactions_MembershipTransaction
+
+MembershipTransaction
+
+
+
+
+treasury_models_SogeCredit->note_models_transactions_MembershipTransaction
+ transactions (_sogecredit_transactions_+)
+
+
+
diff --git a/docs/_static/img/graphs/wei.svg b/docs/_static/img/graphs/wei.svg
new file mode 100644
index 00000000..8167b426
--- /dev/null
+++ b/docs/_static/img/graphs/wei.svg
@@ -0,0 +1,603 @@
+
+
+
+
+
+
+model_graph
+
+wei_models_WEIClub
+
+ WEIClub
+
+club_ptr
+
+
+OneToOneField (id)
+
+
+date_end
+
+
+DateField
+
+
+date_start
+
+
+DateField
+
+
+year
+
+
+PositiveIntegerField
+
+
+
+
+member_models_Club
+
+ Club
+
+id
+
+
+AutoField
+
+
+parent_club
+
+
+ForeignKey (id)
+
+
+email
+
+
+EmailField
+
+
+membership_duration
+
+
+PositiveIntegerField
+
+
+membership_end
+
+
+DateField
+
+
+membership_fee_paid
+
+
+PositiveIntegerField
+
+
+membership_fee_unpaid
+
+
+PositiveIntegerField
+
+
+membership_start
+
+
+DateField
+
+
+name
+
+
+CharField
+
+
+require_memberships
+
+
+BooleanField
+
+
+
+
+wei_models_WEIClub->member_models_Club
+ multi-table
+inheritance
+
+
+
+wei_models_Bus
+
+ Bus
+
+id
+
+
+AutoField
+
+
+wei
+
+
+ForeignKey (club_ptr)
+
+
+description
+
+
+TextField
+
+
+information_json
+
+
+TextField
+
+
+name
+
+
+CharField
+
+
+
+
+wei_models_Bus->wei_models_WEIClub
+ wei (buses)
+
+
+
+wei_models_BusTeam
+
+ BusTeam
+
+id
+
+
+AutoField
+
+
+bus
+
+
+ForeignKey (id)
+
+
+color
+
+
+PositiveIntegerField
+
+
+description
+
+
+TextField
+
+
+name
+
+
+CharField
+
+
+
+
+wei_models_BusTeam->wei_models_Bus
+ bus (teams)
+
+
+
+wei_models_WEIRole
+
+ WEIRole
+
+role_ptr
+
+
+OneToOneField (id)
+
+
+
+
+permission_models_Role
+
+Role
+
+
+
+
+wei_models_WEIRole->permission_models_Role
+ multi-table
+inheritance
+
+
+
+wei_models_WEIRegistration
+
+ WEIRegistration
+
+id
+
+
+AutoField
+
+
+user
+
+
+ForeignKey (id)
+
+
+wei
+
+
+ForeignKey (club_ptr)
+
+
+birth_date
+
+
+DateField
+
+
+caution_check
+
+
+BooleanField
+
+
+clothing_cut
+
+
+CharField
+
+
+clothing_size
+
+
+CharField
+
+
+emergency_contact_name
+
+
+CharField
+
+
+emergency_contact_phone
+
+
+PhoneNumberField
+
+
+first_year
+
+
+BooleanField
+
+
+gender
+
+
+CharField
+
+
+health_issues
+
+
+TextField
+
+
+information_json
+
+
+TextField
+
+
+soge_credit
+
+
+BooleanField
+
+
+
+
+wei_models_WEIRegistration->wei_models_WEIClub
+ wei (users)
+
+
+
+django_contrib_auth_models_User
+
+User
+
+
+
+
+wei_models_WEIRegistration->django_contrib_auth_models_User
+ user (wei)
+
+
+
+wei_models_WEIMembership
+
+ WEIMembership
+
+membership_ptr
+
+
+OneToOneField (id)
+
+
+bus
+
+
+ForeignKey (id)
+
+
+registration
+
+
+OneToOneField (id)
+
+
+team
+
+
+ForeignKey (id)
+
+
+
+
+wei_models_WEIMembership->wei_models_Bus
+ bus (memberships)
+
+
+
+wei_models_WEIMembership->wei_models_BusTeam
+ team (memberships)
+
+
+
+wei_models_WEIMembership->wei_models_WEIRegistration
+ registration (membership)
+
+
+
+member_models_Membership
+
+ Membership
+
+id
+
+
+AutoField
+
+
+club
+
+
+ForeignKey (id)
+
+
+user
+
+
+ForeignKey (id)
+
+
+date_end
+
+
+DateField
+
+
+date_start
+
+
+DateField
+
+
+fee
+
+
+PositiveIntegerField
+
+
+
+
+wei_models_WEIMembership->member_models_Membership
+ multi-table
+inheritance
+
+
+
+member_models_Profile
+
+ Profile
+
+id
+
+
+AutoField
+
+
+user
+
+
+OneToOneField (id)
+
+
+address
+
+
+CharField
+
+
+department
+
+
+CharField
+
+
+email_confirmed
+
+
+BooleanField
+
+
+last_report
+
+
+DateTimeField
+
+
+ml_art_registration
+
+
+BooleanField
+
+
+ml_events_registration
+
+
+CharField
+
+
+ml_sport_registration
+
+
+BooleanField
+
+
+paid
+
+
+BooleanField
+
+
+phone_number
+
+
+PhoneNumberField
+
+
+promotion
+
+
+PositiveSmallIntegerField
+
+
+registration_valid
+
+
+BooleanField
+
+
+report_frequency
+
+
+PositiveSmallIntegerField
+
+
+section
+
+
+CharField
+
+
+
+
+member_models_Profile->django_contrib_auth_models_User
+ user (profile)
+
+
+
+member_models_Club->member_models_Club
+ parent_club (club)
+
+
+
+member_models_Membership->member_models_Club
+ club (membership)
+
+
+
+member_models_Membership->permission_models_Role
+ roles (membership)
+
+
+
+member_models_Membership->django_contrib_auth_models_User
+ user (memberships)
+
+
+
diff --git a/docs/_static/img/treasury_validate_sogecredit.png b/docs/_static/img/treasury_validate_sogecredit.png
new file mode 100644
index 00000000..2902c870
Binary files /dev/null and b/docs/_static/img/treasury_validate_sogecredit.png differ
diff --git a/docs/apps/activity.rst b/docs/apps/activity.rst
new file mode 100644
index 00000000..52f51cbb
--- /dev/null
+++ b/docs/apps/activity.rst
@@ -0,0 +1,110 @@
+Application Activités
+=====================
+
+L'application activités gère les différentes activités liées au BDE. Elle permet entre autres de créer des activités qui
+peuvent être diffusées via des calendriers ou la mailing list d'événements. Elle permet aussi de réguler l'accès aux
+événements, en s'assurant que leur note est positive. Elle permet enfin de gérer les invités.
+
+Modèles
+-------
+
+L'application comporte 5 modèles : activités, types d'activité, invités, entrées et transactions d'invitation.
+
+Types d'activité
+~~~~~~~~~~~~~~~~
+
+Les activités sont triées par type (pots, soirées de club, ...), et chaque type regroupe diverses informations :
+
+* Nom du type
+* Possibilité d'inviter des non-adhérents (booléen)
+* Prix d'invitation (entier, centimes à débiter sur la note de l'hôte)
+
+Activités
+~~~~~~~~~
+
+Le modèle d'activité regroupe les informations liées à l'activité même :
+
+* Nom de l'activité
+* Description de l'activité
+* Créateur, personne qui a proposé l'activité
+* Club ayant organisé l'activité
+* Note sur laquelle verser les crédits d'invitation (peut être nul si non concerné)
+* Club invité (généralement le club Kfet)
+* Date et heure de début
+* Date et heure de fin
+* Activité valide (booléen)
+* Activité ouverte (booléen)
+
+Entrées
+~~~~~~~
+
+Une instance de ce modèle est créé dès que quelqu'un est inscrit à l'activité. Sont stockées les informations suivantes :
+
+* Activité concernée (clé étrangère)
+* Heure d'entrée
+* Note de la personne entrée, ou hôte s'il s'agit d'un invité (clé étrangère vers ``NoteUser``)
+* Invité (``OneToOneField`` vers ``Guest``, ``None`` si c'est la personne elle-même qui rentre et non son invité)
+
+Il n'est pas possible de créer une entrée si la note est en négatif.
+
+Invités
+~~~~~~~
+
+Les adhérents ont la possibilité d'inviter des amis. Pour cela, les différentes informations sont enregistrées :
+
+* Activité concernée (clé étrangère)
+* Nom de famille
+* Prénom
+* Note de la personne ayant invité
+
+Certaines contraintes s'appliquent :
+
+* Une personne ne peut pas être invitée plus de 5 fois par an (coupe nom/prénom)
+* Un adhérent ne peut pas inviter plus de 3 personnes par activité.
+
+Transactions d'invitation
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On étend le modèle ``Transaction`` de l'application note afin de supporter les transactions d'invitation. Elles ne
+comportent qu'un champ supplémentaire, de type ``OneToOneField`` vers ``Guest``.
+
+Ce modèle aurait pu appartenir à l'application ``note``, mais afin de rester modulaire et que l'application ``note``
+ne dépende pas de cette application, on procède de cette manière.
+
+Graphe
+~~~~~~
+
+.. image:: /_static/img/graphs/activity.svg
+ :alt: Graphe de l'application activités
+
+UI
+--
+
+Création d'activités
+~~~~~~~~~~~~~~~~~~~~
+
+N'importe quel adhérent Kfet peut suggérer l'ajout d'une activité via un formulaire.
+
+Gestion des activités
+~~~~~~~~~~~~~~~~~~~~~
+
+Les ayant-droit (Res[pot] et respos infos) peuvent valider les activités proposées. Ils peuvent également la modifier
+si besoin. Ils peuvent enfin la déclarer ouvertes pour lancer l'accès aux entrées.
+
+N'importe qui peut inviter des amis non adhérents, tant que les contraintes de nombre (un adhérent n'invite pas plus de
+trois personnes par activité et une personne ne peut pas être invitée plus de 5 fois par an). L'invitation est
+facturée à l'entrée.
+
+Entrées aux soirées
+~~~~~~~~~~~~~~~~~~~
+
+L'interface d'entrées est simple et ergonomique. Elle contient un champ de texte. À chaque fois que le champ est
+modifié, un tableau est affiché comprenant la liste des invités et des adhérents dont le prénom, le nom ou un alias
+de la note est acceptée par le texte entré.
+
+En cliquant sur la ligne de la personne qui souhaite rentrée, s'il s'agit d'un adhérent, alors la personne est comptée
+comme entrée à l'activité, sous réserve que sa note soit positive. S'il s'agit d'un invité, alors 3 boutons
+apparaîssent, afin de régler la taxe d'invitation : l'un prélève directement depuis la note de l'hôte, les deux autres
+permettent un paiement par espèces ou par carte bancaire. En réalité, les deux derniers boutons enregistrent
+automatiquement un crédit sur la note de l'hôte, puis une transaction (de type ``GuestTransaction``) est faite depuis
+la note de l'hôte vers la note de l'organisateur de l'événement.
diff --git a/docs/apps/api.rst b/docs/apps/api.rst
new file mode 100644
index 00000000..56d6b5df
--- /dev/null
+++ b/docs/apps/api.rst
@@ -0,0 +1,170 @@
+API
+===
+
+La NoteKfet2020 dispose d'une API REST. Elle est accessible sur `/api/ /`` affiche la liste de tous les éléments enregistrés. La page ``/api///`` affiche
+les attributs d'un objet uniquement.
+
+L'affichage des données peut se faire sous deux formes : via une interface HTML propre ou directement en affichant
+le JSON brut. Le changement peut se faire en ajoutant en paramètre de l'URL ``format=json`` ou ``format=api`, ou bien
+en plaçant en en-tête de la requête ``Accept: application/json`` ou ``text/html``.
+
+L'API Web propose des formulaires facilitant l'ajout et la modification d'éléments.
+
+GET
+~~~
+
+Une requête GET affiche un ou des éléments. Si on veut la liste de tous les éléments d'un modèle, la réponse
+est de cette forme :
+
+.. code:: json
+
+ {
+ "count": "",
+ "next": "/api//?page=",
+ "previous": "/api//?page=",
+ "results": [ ]
+ }
+
+Où ```` est le nombre d'éléments trouvés. La page n'affiche les informations que 20 par 20 pour ne pas
+augmenter inutilement la taille de la réponse. Les champs ``next`` et ``previous`` contiennent les URL des pages
+suivantes et précédentes (``null`` si première ou dernière page). Le champ ``results`` contient enfin l'ensemble des
+objets trouvés, au format JSON.
+
+Certaines pages disposent de filtres, permettant de sélectionner les objets recherchés. Par exemple, il est possible
+de chercher une note d'un certain type matchant avec un certain alias.
+
+Le résultat est déjà par défaut filtré : seuls les éléments que l'utilisateur à le droit de voir sont affichés.
+Cela est possible grâce à la structure des permissions, générant justement des filtres de requêtes de base de données.
+
+Une requête à l'adresse ``/api//pk/`` affiche directement les informations du modèle demandé au format JSON.
+
+POST
+~~~~
+
+Une requête POST permet d'ajouter des éléments. Cette requête n'est possible que sur la page ``/api//``,
+la requête POST n'est pas supportée sur les pages de détails (car cette requête permet ... l'ajout).
+
+Des exceptions sont faites sur certaines pages : les pages de logs et de contenttypes sont en lecture uniquement.
+
+Les formats supportés sont multiples : ``application/json``, ``application/x-www-url-encoded``, ``multipart/form-data``.
+Cela facilite l'envoi de requêtes. Le module construit ensuite l'instance du modèle et le sauvegarde dans la base de
+données. L'application ``permission`` s'assure que l'utilisateur à le droit de faire ce type de modification. La réponse
+renvoyée est l'objet enregistré au format JSON si l'ajout s'est bien déroulé, sinon un message d'erreur au format JSON.
+
+PATCH
+~~~~~
+
+Une requête PATCH permet de modifier un élément. Ce type de requête n'est disponible que sur la page de détails d'un
+élément : ``/api//pk/``.
+
+Comme pour la requête POST, les formats supportés sont multiples : ``application/json``,
+``application/x-www-url-encoded``, ``multipart/form-data``.
+
+Il n'est pas utile d'indiquer tous les champs du modèle : seuls ceux qui sont à modifier suffisent.
+
+Attention : pour les modèles polymorphiques (``Note``, ``Transaction``), il faut toujours spécifier le type de modèle
+pour que l'API arrive à s'y retrouver. Par exemple, si on veut rendre la transaction n°42 non valide, on effectue une
+requête ``PATCH`` sur ``/api/note/transaction/transaction/42/`` avec les données suivantes :
+
+.. code:: json
+
+ {
+ "valid": false,
+ "resourcetype": "RecurrentTransaction"
+ }
+
+PUT
+~~~
+
+Une requête PUT permet de remplacer un élément. Ce type de requête n'est disponible que sur la page de détails d'un
+élément : ``/api//pk/``.
+
+Comme pour les requêtes POST ou PATCH, les formats supportés sont multiples : ``application/json``,
+``application/x-www-url-encoded``, ``multipart/form-data``.
+
+Contrairement à la requête PATCH, l'intégralité du modèle est remplacé. L'ancien modèle est détruit, on en recrée un
+nouveau avec la même clé primaire. Le fonctionnement est similaire à une requête POST.
+
+DELETE
+~~~~~~
+
+Une requête de type DELETE permet de supprimer un élément. Ce type de requête n'est disponible que sur la page de
+détails d'un élément : ``/api//pk/``.
+
+Aucune donnée n'est nécessaire. Le module de permissions vérifiera que la suppression est possible. Une erreur
+est sinon renvoyée.
+
+OPTIONS
+~~~~~~~
+
+Une reqête OPTIONS affiche l'ensemble des opérations possibles sur un modèle ou une instance. Prototype d'une réponse :
+
+.. code:: json
+
+ {
+ "name": "",
+ "description": "",
+ "renders": [
+ "application/json",
+ "text/html"
+ ],
+ "parses": [
+ "application/json",
+ "application/x-www-form-urlencoded",
+ "multipart/form-data"
+ ],
+ "actions": {
+ "": {
+ "": {
+ "type": "",
+ "required": "",
+ "read_only": "",
+ "label": ""
+ }
+ }
+ }
+ }
+
+* ```` est le type de requête HTTP supporté (pour modification, inclus dans {``POST``, ``PUT``, ``PATCH``}).
+* ```` est le nom du champ dans le modèle concerné (exemple : ``id``)
+* ```` représente le type de données : ``integer``, ``string``, ``date``, ``choice``, ``field`` (pour les clés étrangères), ...
+* ```` est un booléen indiquant si le champ est requis dans le modèle ou s'il peut être nul/vide.
+* ```` est un booléen indiquant si le champ est accessible en lecture uniquement.
+* ```` représente le label du champ, son nom traduit, qui s'affiche dans le formulaire accessible sur l'API Web.
+
+Des contraintes peuvent s'ajouter à cela selon les champs : taille maximale de chaînes de caractères, valeurs minimales
+et maximales pour les entiers ...
\ No newline at end of file
diff --git a/docs/apps/index.rst b/docs/apps/index.rst
new file mode 100644
index 00000000..6810be56
--- /dev/null
+++ b/docs/apps/index.rst
@@ -0,0 +1,71 @@
+Applications de la NoteKfet2020
+===============================
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Applications
+
+ member
+ note/index
+ activity
+ permission
+ api
+ registration
+ logs
+ treasury
+ wei
+
+La NoteKfet est un projet Django, décomposé en applications.
+Certaines Applications sont développées uniquement pour ce projet, et sont indispensables, d'autre sont packagé et sont installées comme dépendances.
+Enfin Des fonctionnalités annexes ont été rajouté, mais ne sont pas essentiel au déploiement de la NoteKfet; leur usage est cependant recommandé.
+
+Le front utilise le framework Bootstrap4 et quelques morceaux de javascript custom.
+
+Applications indispensables
+---------------------------
+
+* ``note_kfet`` :
+ Application "projet" de django, c'est ici que la config de la note est gérée.
+* `Member `_ :
+ Gestion des profils d'utilisateurs, des clubs et de leur membres.
+* `Note `_ :
+ Les notes associés a des utilisateurs ou des clubs.
+* `Activity `_ :
+ La gestion des Activités (créations, gestion, entrée...)
+* `Permission `_ :
+ Backend de droits, limites les pouvoirs des utilisateurs
+* `API `_ :
+ API REST de la note, est notamment utilisée pour rendre la note dynamique
+ (notamment la page de conso)
+* `Registration `_ :
+ Gestion des inscriptions à la Note Kfet
+
+
+Applications packagées
+----------------------
+* ``polymorphic``
+ Utiliser pour la création de models polymorphiques (``Note`` et ``Transaction`` notamment) cf [Note](Note).
+
+ L'utilisation des models polymorphiques est détaillé sur la documentation du package:
+ ``_.
+
+Applications facultatives
+-------------------------
+* `Logs `_
+ Enregistre toute les modifications effectuées en base de donnée.
+* ``cas-server``
+ Serveur central d'authenfication, permet d'utiliser son compte de la NoteKfet2020 pour se connecter à d'autre application ayant intégrer un client.
+* `Script `_
+ Ensemble de commande `./manage.py` pour la gestion de la note: import de données, verification d'intégrité, etc ...
+* `Treasury `_ :
+ Interface de gestion pour les trésoriers, émission de facture, remise de chèque, statistiques ...
+* `WEI `_ :
+ Interface de gestion du WEI.
+
diff --git a/docs/apps/logs.rst b/docs/apps/logs.rst
new file mode 100644
index 00000000..dc25423c
--- /dev/null
+++ b/docs/apps/logs.rst
@@ -0,0 +1,50 @@
+Logs
+====
+
+Chaque modification effectuée sur un modèle est enregistrée dans la base dans données.
+
+Dès qu'un modèle veut être sauvegardé, deux signaux sont envoyés dans ``logs.signals`` : un avant et un après
+la sauvegarde.
+En pré-sauvegarde, on récupère l'ancienne version du modèle, si elle existe.
+En post-sauvegarde, on récupère l'utilisateur et l'IP courants (voir ci-dessous), on convertit les modèles en JSON
+et on enregistre une entrée ``Changelog`` dans la base de données.
+
+Pour récupérer l'utilisateur et son IP, le middleware ``logs.middlewares.LogsMiddlewares`` récupère à chaque requête
+l'utilisateur et l'adresse IP, et les stocke dans le processus courant, afin qu'ils puissent être
+récupérés par les signaux.
+
+Si jamais la modification ne provient pas d'une requête Web, on suppose qu'elle vient d'une instruction
+lancée avec ``manage.py``.
+On récupère alors le nom de l'utilisateur dans l'interface de commandes, et si une note est associée à cet alias,
+alors on considère que c'est le détenteur de la note qui a effectué cette modification, sur l'adresse IP ``127.0.0.1``.
+Sinon, le champ est laissé à ``None``.
+
+Une entrée de ``Changelog`` contient les informations suivantes :
+
+ * Utilisateur (``ForeignKey`` vers ``User``, nullable)
+ * Adresse IP (``GenericIPAddressField``)
+ * Type de modèle enregistré (``ForeignKey`` vers ``Model``)
+ * Identifiant ``pk`` de l'instance enregistrée (``CharField``)
+ * Anciennes données (au format JSON, ``None`` si création de données)
+ * Nouvelles données (au format JSON, ``None`` si suppression de données)
+ * Action (``CharField`` avec choix ``create``, ``edit``, ``delete``)
+ * Date de modification (``DateTimeField``)
+
+Exemple de Changelog, pour la création d'une transaction de 42424242 centimes d'une note vers une autre :
+
+.. code:: json
+
+ {
+ "id": 42,
+ "ip": "192.168.0.1",
+ "instance_pk": "1",
+ "previous": null,
+ "data": "{\"id\":1,\"created_at\":\"2020-03-11T17:24:09.858651+01:00\",\"quantity\":1,\"amount\":42424242,\"reason\":\"Volons la Kfet\",\"valid\":true,\"polymorphic_ctype\":36,\"source\":6,\"destination\":7}",
+ "action": "create",
+ "timestamp": "2020-03-11T17:24:10.088151+01:00",
+ "user": 1,
+ "model": 36
+ }
+
+S'il est préférable de passer en console Postgresql pour parcourir les logs, ils sont trouvables via l'API dans
+``/api/logs``, sous réserve d'avoir les droits suffisants (ie. être respo info).
diff --git a/docs/apps/member.rst b/docs/apps/member.rst
new file mode 100644
index 00000000..e8e57bcd
--- /dev/null
+++ b/docs/apps/member.rst
@@ -0,0 +1,144 @@
+Application Member
+==================
+
+L'application ``member`` s'occcupe de la gestion des utilisateurs enregistrés.
+
+Le model d'utilisateur ``django.contrib.auth.model.User`` est complété par un ``Profile`` utilisateur.
+
+Tous les utilisateurs peuvent être membre de ``Club``. Cela se traduit par une adhésion ``Membership``, dont les
+caractéristiques sont propres à chaque club.
+
+En pratique, la NoteKfet possède au minimum deux Club: **Bde** et **Kfet** (instanciés via les fixtures). Et tous
+les personnes à jour de cotisation sont membre à minima de Bde.
+Être adhérent du club Kfet permet d'utiliser sa note pour consommer.
+
+Modèles
+-------
+
+Utilisateur
+~~~~~~~~~~~
+
+Le modèle ``User`` est directement implémenté dans Django et n'appartient pas à l'application ``member``, mais il est
+bon de rappeler à quoi ressemble ce modèle.
+
+* ``date_joined`` : ``DateTimeField``, date à laquelle l'utilisateur a été inscrit (*inutilisé dans la Note*)
+* ``email`` : ``EmailField``, adresse e-mail de l'utilisateur.
+* ``first_name`` : ``CharField``, prénom de l'utilisateur.
+* ``is_active`` : ``BooleanField``, indique si le compte est actif et peut se connecter.
+* ``is_staff`` : ``BooleanField``, indique si l'utilisateur peut se connecter à l'interface Django-admin.
+* ``is_superuser`` : ``BooleanField``, indique si l'utilisateur dispose de droits super-utilisateurs, permettant n'importe quelle action en base de donnée (lecture, ajout, modification, suppression).
+* ``last_login`` : ``DateTimeField``, date et heure de dernière connexion.
+* ``last_name`` : ``CharField``, nom de famille de l'utilisateur.
+* ``password`` : ``CharField``, contient le hash du mot de passe de l'utilisateur. L'algorithme utilisé est celui par défaut de Django : PBKDF2 + HMAC + SHA256 avec 150000 itérations.
+* ``username`` : ``CharField`` (unique), pseudo de l'utilisateur.
+
+Profil
+~~~~~~
+
+Le modèle ``Profile`` contient un champ ``user`` de type ``OneToOneField``, ce qui permet de voir ce modèle comme une
+extension du modèle ``User``, sans avoir à le réécrire. Il contient diverses informations personnelles sur
+l'utilisateur, utiles pour l'adhésion au BDE :
+
+* ``user`` : ``OneToOneField(User)``, utilisateur lié à ce profil
+* ``address`` : ``CharField``, adresse physique de l'utilisateur
+* ``paid`` : ``BooleanField``, indique si l'utilisateur normalien est rémunéré ou non (utile pour différencier les montants d'adhésion aux clubs)
+* ``phone_number`` : ``CharField``, numéro de téléphone de l'utilisateur
+* ``section`` : ``CharField``, section de l'ENS à laquelle apartient l'utilisateur (exemple : 1A0, ...)
+
+Clubs
+~~~~~
+
+La gestion des clubs est une différence majeure avec la Note Kfet 2015. La Note gère ainsi les adhésions des
+utilisateurs aux différents clubs.
+
+* ``parent_club`` : ``ForeignKey(Club)``. La présence d'un club parent force l'adhésion au club parent avant de pouvoir adhérer au dit club. Tout club qui n'est pas le club BDE doit avoir le club BDE dans son arborescence.
+* ``email`` : ``EmailField``, adresse e-mail sur laquelle contacter le bureau du club.
+* ``membership_start`` : ``DateField``, date à partir de laquelle il est possible d'adhérer à un club pour l'année suivante (si adhésions à l'année), en ignorant l'année. Par exemple, l'adhésion BDE est possible à partir du 31/08 par défaut, et c'est à cette date que les adhésions pour l'année future est possible.
+* ``membership_end`` : ``DateField``, date maximale de fin d'adhésion. Pour le club BDE, il s'agit du 30/09 de l'année suivante. Si cette valeur vaut ``null``, la fin d'adhésion n'est pas limitée.
+* ``membership_duration`` : ``PositiveIntegerField``, durée (en jours) maximale d'adhésion. Par exemple, le club BDE permet des adhésions maximales de 13 mois, soit 396 jours.
+* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un élève normalien (donc rémunéré) puisse adhérer.
+* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un étudiant normalien (donc non rémunéré) puisse adhérer.
+* ``name`` : ``CharField``, nom du club.
+* ``require_memberships`` : ``BooleanField``, indique si le club est un vrai club BDE qui nécessite des adhésions de club, ou s'il s'agit d'une note "pot commun" (organisation d'une activité, note de département, ...)
+
+Adhésions
+~~~~~~~~~
+
+Comme indiqué précédemment, la note gère les adhésions.
+
+* ``club`` : ``ForeignKey(Club)``, club lié à l'adhésion.
+* ``user`` : ``ForeignKey(User)``, utilisateur adhéré.
+* ``date_start`` : ``DateField``, date de début d'adhésion.
+* ``date_end`` : ``DateField``, date de fin d'adhésion.
+* ``fee`` : ``PositiveIntegerField``, montant de la cotisation payée.
+* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent.
+
+Rôles
+~~~~~
+
+Comme indiqué le modèle des adhésions, les adhésions octroient des rôles aux adhérents, qui offrent des permissions
+(cf ``RolesPermissions`` dans la page des permissions). Le modèle ``RolesPermissions`` possède un
+``OneToOneField(Role)``, qui implémente les permissions des rôles. Le modèle ``Role`` à proprement parler ne contient
+que le champ de son nom (``CharField``).
+
+Transactions d'adhésion
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Si le modèle ``MembershipTransaction`` appartient à l'application ``note``, il est bon d'en parler ici.
+Le modèle ``MembershipTransaction`` est une extension du modèle ``Transaction`` (application ``note``) qui est de type
+polymorphique, et contient en plus des informations de base de la transaction un champ ``OneToOneField(Membership)``
+faisant le lien entre l'adhésion et la transaction liée. Une adhésion club, si elle n'est pas gratuite,
+génère en effet automatiquement une transaction de l'utilisateur vers le club (voir section adhésions).
+
+Graphe
+------
+
+.. image:: /_static/img/graphs/member.svg
+ :alt: Graphe de l'application member
+
+Adhésions
+---------
+
+La Note Kfet offre la possibilité aux clubs de gérer l'adhésion de leurs membres. En plus de réguler les cotisations
+des adhérents, des permissions sont octroyées sur la note en fonction des rôles au sein des clubs. Un rôle est une
+fonction occupée au sein d'un club (Trésorier de club, président de club, GCKfet, Res[pot], respo info, ...).
+Une adhésion attribue à un adhérent ses rôles. Les rôles fournissent les permissions. Par exemple, le trésorier d'un
+club a le droit de faire des transferts de et vers la note du club, tant que la source reste au-dessus de -50 €.
+Une adhésion est considérée comme valide si la date du jour est comprise (au sens large) entre les dates de début et
+de fin d'adhésion.
+
+On peut ajouter une adhésion à un utilisateur dans un club à tout non adhérent de ce club. La personne en charge
+d'adhérer quelqu'un choisit l'utilisateur, les rôles au sein du club et la date de début d'adhésion. Cette date de
+début d'adhésion doit se situer entre les champs ``club``.``membership_start`` et ``club``.``membership_end``,
+si ces champs sont non nuls. Si ``club``.``parent_club`` n'est pas nul, l'utilisateur doit être membre de ce club.
+Le montant de la cotisation est fixé en fonction du statut normalien de l'utilisateur (``club``.``membership_fee_paid``
+centimes pour les élèves et ``club``.``membership_fee_unpaid`` centimes pour les étudiants). La date de fin est calculée
+comme ce qui suit :
+
+* Si ``club``.``membership_duration`` est non nul, alors ``date_end`` = ``date_start`` + ``club.membership_duration``
+* Sinon ``club``, ``date_end`` = ``date_start`` + 424242 jours (suffisant pour tenir au moins une vie)
+* Si ``club``.``membership_end`` est non nul, alors ``date_end`` = min(``date_end``, ``club``.``membership_end``)
+
+Si l'utilisateur n'est pas membre du club ``Kfet``, l'adhésion n'est pas possible si le solde disponible sur sa note est
+insuffisant. Une fois toute ces contraintes vérifiées, l'adhésion est créée. Une transaction de type
+``MembershipTransaction`` est automatiquement créée de la note de l'utilisateur vers la note du club, finalisant l'adhésion.
+
+Réadhésions
+~~~~~~~~~~~
+
+Pour les clubs nécessitant des adhésions (de durée limitée), il est possible de réadhérer au bout d'un an. Dès lors
+que le jour actuel est après ``club``.``membership_start`` + 1 an, ``club``.``membership_start`` et
+``club``.membership_end`` sont incrémentés d'un an.
+
+Il est possible de réadhérer si :
+* ``membership``.``date_start`` <= ``today`` <= ``membership``.``date_end`` (l'adhésion en cours est valide)
+* ``membership``.``date_start`` < ``club``.``membership_start`` (si la date de début d'adhésion du club est postérieure à la date de début d'adhésion, qui a donc été mise à jour, on a changé d'année)
+* Il n'y a pas encore de réadhésion (pas d'adhésion au même club vérifiant ``new_membership``.``date_start`` >= ``club``.``membership_start``)
+
+Un bouton ``Réadhérer`` apparaît dans la liste des adhésions si le droit est permis et si ces contraintes sont vérifiées.
+En réadhérant, une nouvelle adhésion est créée pour l'utilisateur avec les mêmes rôles, commençant le lendemain de la
+date d'expiration de la précédente adhésion. Si on réadhère le 16 août pour une adhésion finissant le 30 septembre,
+la nouvelle adhésion commencera le 1er octobre).
+
+Pour supprimer une adhésion (en cas d'erreur), se rendre dans django admin et changer la date de fin d'adhésion,
+sans oublier d'invalider la transaction d'adhésion.
diff --git a/docs/apps/note/consumptions.rst b/docs/apps/note/consumptions.rst
new file mode 100644
index 00000000..5b91934c
--- /dev/null
+++ b/docs/apps/note/consumptions.rst
@@ -0,0 +1,88 @@
+Consommations
+=============
+
+Affichage
+---------
+
+La page de consommations est principalement une communication entre l'`API <../api>`_ et la page en JavaScript.
+Elle est disponible à l'adresse ``/note/consos/``, et l'onglet n'est visible que pour ceux ayant le droit de voir au
+moins un bouton. L'affichage, comme tout le reste de la page, est géré avec Boostrap 4.
+Les boutons que l'utilisateur a le droit de voir sont triés par catégorie.
+
+## Sélection des consommations
+
+Lorsque l'utilisateur commence à taper un nom de note, un appel à l'API sur la page ``/api/note/alias`` est fait,
+récupérant les 20 premiers aliases en accord avec la requête. Quand l'utilisateur survole un alias, un appel à la page
+``/api/note/note//`` est fait pour récupérer plus d'infos sur la note telles que le solde, le vrai nom de la
+note et la photo, si toutefois l'utilisateur a le droit de voir ceci.
+
+L'utilisateur peut cliquer sur des aliases pour ajouter des émetteurs, et sur des boutons pour ajouter des consommations.
+Cliquer dans la liste des émetteurs supprime l'élément sélectionné.
+
+Il ya deux possibilités pour faire consommer des adhérents :
+ - En mode **consommation simple** (mode par défaut), les consommations sont débitées dès que émetteurs et consommations
+ sont renseignées.
+ - En mode **consommation double**, l'utilisateur doit cliquer sur "Consommer !" pour débiter toutes les consommations.
+
+Débit des consommations
+-----------------------
+
+Pour débiter toutes les consommations, pour chaque source et chaque bouton, une requête POST est faite à l'API sur
+l'adresse ``/api/note/transaction/transaction/`` avec le contenu suivant :
+
+.. code:: json
+
+ {
+ "quantity": "",
+ "amount": "",
+ "reason": " ()",
+ "valid": true,
+ "polymorphic_ctype": 42,
+ "source": "",
+ "destination": "",
+ "template": "",
+ "category": "",
+ "resourcetype": "RecurrentTransaction"
+ }
+
+Par exemple, pour 3 cocas à 1.10 € (catégorie Soft, numéro 1), bouton numéro 1, à destination de la note Kfet (id 6)
+depuis la note 7, la requête suivante est envoyée :
+
+.. code:: json
+
+ {
+ "quantity": 3,
+ "amount": 110,
+ "reason": "Coca (Soft)",
+ "valid": true,
+ "polymorphic_ctype": 42,
+ "source": 7,
+ "destination": 6,
+ "template": 1,
+ "category": 1,
+ "resourcetype": "RecurrentTransaction"
+ }
+
+Le ``42`` dans ``"polymorphic_ctype": 42`` correspond à l'identifiant du modèle `RecurrentTransaction` dans la table
+des types. Il vaut `42` lors de la rédaction de cette documentation, mais pourra varier à l'avenir, et sera toujours
+à jour : la valeur n'est pas "hard-codée".
+
+Si une erreur survient lors de la requête (droits insuffisants), un message apparaîtra en haut de page.
+Dans tous les cas, tous les champs sont réinitialisés.
+
+L'historique et la balance de l'utilisateur sont ensuite mis à jour via jQuery, qui permet de recharger une partie de page Web.
+
+Validation/dévalidation des transactions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Il est possible aussi de (dé)valider une transaction en cliquant sur le symbole de validation. Lorsqu'un clic est fait,
+une requête PATCH est faite à l'API sur l'adresse ``/api/note/transaction/transaction//`` de la forme :
+
+.. code:: json
+
+ {
+ "resourcetype": "RecurrentTransaction",
+ "valid": false
+ }
+
+L'historique et la balance sont ensuite rafraîchis. Si une erreur survient, un message apparaîtra.
diff --git a/docs/apps/note/index.rst b/docs/apps/note/index.rst
new file mode 100644
index 00000000..039efb3a
--- /dev/null
+++ b/docs/apps/note/index.rst
@@ -0,0 +1,23 @@
+Application Note
+================
+
+L'application ``note`` gère tout ce qui est en lien avec les flux d'argent et les notes (balances) des utilisateurs.
+
+La gestion des consommations s'effectue principalement via la page dédiée, dont le fonctionnement est expliqué
+dans la page `Consommations `_.
+
+Le fonctionnnemnent des crédit/débit de note (avec le "monde extérieur" donc avec de l'argent réel) ainsi que les
+transferts/dons entre notes est détaillé sur la page `Transferts `_.
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Note
+
+ consumptions
+ transfers
+
+Graphe
+------
+
+.. image:: /_static/img/graphs/note.svg
+ :alt: Graphe de l'application note
diff --git a/docs/apps/note/transfers.rst b/docs/apps/note/transfers.rst
new file mode 100644
index 00000000..5438665e
--- /dev/null
+++ b/docs/apps/note/transfers.rst
@@ -0,0 +1,34 @@
+Transferts
+==========
+
+Affichage
+---------
+
+L'interface de la page de transferts est semblable à celles des consommations, et l'auto-complétion de note est géré de
+la même manière. La page se trouve à l'adresse ``/note/transfer/``. La liste des 20 transactions les plus récentes que
+l'utilisateur a le droit de voir est également présente.
+
+Des boutons ``Don``, ``Transfert``, ``Crédit``, ``Retrait`` sont présents, représentant les différents modes de
+transfert. Pour chaque transfert, un montant et une description sont attendus.
+
+Onglet transferts
+-----------------
+
+Cet onglet est visible par tout le monde. Il permet d'effectuer un transfert depuis plusieurs notes vers d'autres notes,
+à l'image des consommations doubles. Si une erreur survient (permission insuffisante), un message d'erreur apparaîtra.
+
+Onglets Crédit et retrait
+-------------------------
+
+Ces onglets ne sont visibles que par ceux qui ont le droit de voir les ``SpecialNote``.
+
+Une boîte supplémentaire apparaît, demandant en plus de la note, du montant et de la raison le nom, le prénom et
+la banque de la personne à recharger/retirer. Lorsqu'une note est sélectionnée, les champs "nom" et "prénom" sont
+remplis automatiquement. Par ailleurs, seule une note peut être choisie.
+
+Transfert
+---------
+
+Les transferts se font à nouveau via l'API, avec le même schéma que précédemment, en remplaçant
+``RecurrentTransaction`` par ``Transaction`` simplement pour don/transfert, et ``SpecialTransaction`` pour
+crédit/retrait, en adaptant le champ ``polymorphic_ctype``.
diff --git a/docs/apps/permission.rst b/docs/apps/permission.rst
new file mode 100644
index 00000000..aa6e1811
--- /dev/null
+++ b/docs/apps/permission.rst
@@ -0,0 +1,151 @@
+Droits
+======
+
+Le système de droit par défault de django n'est pas suffisament granulaire pour les besoins de la NoteKfet2020.
+Un système custom a donc été développé.
+
+Il permet la création de Permission, qui autorise ou non a faire une action précise sur un ou des objets
+de la base de données.
+
+Plusieurs permissions peuvent être regroupé dans un Role.
+Ce Role est relié a la responsabilité/fonction de la personne dans un Club. Ils sont valable au maximum tant que la
+personne est adhérente du Club concerné, mais ce rôle peut être modifié/supprimé avant le terme.
+
+Permission
+----------
+
+Une permission est un Model Django dont les principaux attributs sont :
+
+* ``model`` : Le model sur lequel cette permission va s'appliquer
+* ``type`` : Les différents types d'interaction sont : voir (``view``), modifier (``change``), ajouter (``add``)
+ et supprimer (``delete``).
+* ``query`` : Requete sur la cible, encodé en JSON, traduit en un Q object (cf [Query](#compilation-de-la-query)
+* ``field`` : le champ cible qui pourra etre modifié. (tous les champs si vide)
+
+Pour savoir si un utilisateur a le droit sur un modèle ou non, la requête est compilée (voir ci-dessous) en un filtre
+de requête dans la base de données, un objet de la classe ``Q`` (En SQL l'objet Q s'interprete comme tout ce qui suit
+un ``WHERE ...`` Ils peuvent être combiné à l'aide d'opérateurs logiques. Plus d'information sur les Q object dans la
+`documentation officielle `_.
+
+Ce Q object sera donc utilisé pour savoir si l'instance que l'on veux modifier est concernée par notre permission.
+
+Exception faite sur l'ajout d'objets : l'objet n'existant pas encore en base de données, il est ajouté puis supprimé
+à la volée, en prenant soin de désactiver les signaux.
+
+Compilation de la query
+-----------------------
+
+La query est enregistrée sous un format JSON, puis est traduite en requête ``Q`` récursivement en appliquant certains paramètres.
+Le fonctionnemente de base des permission peux être décris avec les differents opérations :
+
++----------------+-----------------------------+-------------------------------------+
+| opérations | JSON | Q object |
++================+=============================+=====================================+
+| ALL | ``[]`` ou ``{}`` | ``.objects.get(Q(pk=F("pk"))`` |
++----------------+-----------------------------+-------------------------------------+
+| ET | ``["AND", Q_1, Q_2, ... ]`` | ``.objects.get(Q_1 & Q_2 & ...)`` |
++----------------+-----------------------------+-------------------------------------+
+| OU | ``["OR", Q_1, Q_2, ...]`` | ``.objects.get(Q_1 \| Q_2 \| ...)`` |
++----------------+-----------------------------+-------------------------------------+
+| NON | ``["NOT", Q_1]`` | ``.objects.get(~Q_1)`` |
++----------------+-----------------------------+-------------------------------------+
+| key == value | ``{key: value}`` | ``.objects.get(Q(key = value))`` |
++----------------+-----------------------------+-------------------------------------+
+
+
+Vous n'avez rien compris ? Voilà des exemples :
+
+Exemples
+--------
+
+* Permission sur le model ``User`` avec comme query:
+
+ .. code:: js
+
+ {"is_superuser": true}
+
+ | si l'utilisateur cible est un super utilisateur.
+
+* sur le model ``Note`` :
+
+ .. code:: js
+
+ {"pk":
+ ["user","note", "pk"]
+ }
+
+ | si l'identifiant de la note cible est l'identifiant de l'utilisateur dont on regarde la permission.
+
+* sur le model ``Transaction``:
+
+ .. code:: js
+
+ ["AND",
+ {"source":
+ ["user", "note"]},
+ {"amount__lte":
+ ["user", "note", "balance"]}
+ ]
+
+ | si la source est la note de l'utilisateur et si le montant est inférieur à son solde.
+
+* Sur le model ``Alias``
+
+ .. code:: js
+
+ ["OR",
+ {"note__in":
+ ["NoteUser", "objects",[
+ "filter",{
+ "user__membership__club__name": "Kfet"
+ }],
+ ["all"]
+ ]},
+ {"note__in":
+ ["NoteClub", "objects", ["all"]]
+ }
+ ]
+
+ | si l'alias appartient à une note de club ou s'il appartient à la note d'un utilisateur membre du club Kfet.
+
+* sur le model ``Transaction``
+
+ .. code:: js
+
+ ["AND",
+ {"destination": ["club", "note"]},
+ {"amount__lte":
+ {"F": [
+ "ADD",
+ ["F", "source__balance"],
+ 5000]
+ }
+ }
+ ]
+
+ | si la destination est la note du club dont on est membre et si le montant est inférieur au solde de la source + 50 €,
+ autrement dit le solde final est au-dessus de -50 €.
+
+
+Masques de permissions
+----------------------
+
+Chaque permission est associée à un masque. À la connexion, l'utilisateur choisit le masque de droits avec lequel il
+souhaite se connecter. Les masques sont ordonnés totalement, et l'utilisateur aura effectivement une permission s'il est
+en droit d'avoir la permission et si son masque est suffisamment haut.
+
+Par exemple, si la permission de voir toutes les transactions est associée au masque "Droits note uniquement",
+se connecter avec le masque "Droits basiques" n'octroiera pas cette permission tandis que le masque "Tous mes droits" oui.
+
+Signaux
+-------
+
+À chaque fois qu'un modèle est modifié, ajouté ou supprimé, les droits sont contrôlés. Si les droits ne sont pas
+suffisants, une erreur est lancée. Pour ce qui est de la modification, on ne contrôle que les champs réellement
+modifiés en comparant l'ancienne et la nouvele instance.
+
+Graphe des modèles
+------------------
+
+.. image:: /_static/img/graphs/permission.svg
+ :alt: Graphe de l'application permission
diff --git a/docs/apps/registration.rst b/docs/apps/registration.rst
new file mode 100644
index 00000000..c5947349
--- /dev/null
+++ b/docs/apps/registration.rst
@@ -0,0 +1,61 @@
+Inscriptions
+============
+
+L'inscription a la note se fait via une application dédiée, sans toutefois avoir de modèle en base de données.
+
+Un formulaire d'inscription est disponible sur la page ``/registration/signup``, accessible depuis n'importe qui,
+authentifié ou non. Les informations suivantes sont demandées :
+
+* Prénom
+* Nom de famille
+* Adresse électronique valide
+* Mot de passe
+* Confirmation du mot de passe
+* Numéro de téléphone (optionnel)
+* Département d'études
+* Promotion, année d'entrée à l'ENS
+* Adresse (optionnel)
+* Payé (si la personne perçoit un salaire)
+
+Le mot de passe doit vérifier des contraintes de longueur, de complexité et d'éloignement des autres informations
+personnelles.
+
+Le compte est ensuite créé, mais est inactif : la personne ne peut pas se connecter. Elle reçoit un mail lui
+demandant de vérifier son adresse. Une fois le lien cliqué, l'adresse mail est validée, mais le compte reste
+inactif et la connexion impossible.
+
+Pour valider son compte, il faut se rendre à la Kfet et payer les 5 € d'adhésion BDE (ou 40 € si adhésion Kfet en plus,
+15 € si on est après le 1er mars), ou bien dire qu'on a ouvert un compte à la Société générale qui paiera alors
+l'adhésion. Le BDE pourra alors contrôler les informations du nouveau venu et valider son inscription.
+Toutefois, même si l'inscription est validée, l'inscription restera impossible tant que l'adresse e-mail ne sera pas
+validée. Le BDE peut mettre à jour l'adresse e-mail si besoin. Dès lors que l'adresse e-mail sera validée,
+le compte sera enfin actif.
+
+Pour récapituler : compte actif = adresse e-mail validée + inscription validée par le BDE.
+
+Lors de la validation de l'inscription, le BDE peut (et doit même) faire un crédit initial sur la future note de
+l'utilisateur. Il peut spécifier le type de crédit (carte bancaire/espèces/chèque/virement bancaire), le prénom,
+le nom et la banque comme un crédit normal. Cependant, il peut aussi cocher une case "Société générale", si le nouveau
+membre indique avoir ouvert un compte à la Société générale via le partenariat Société générale - BDE de
+l'ÉNS Paris-Saclay. Dans ce cas, tous les champs sont grisés.
+
+Une fois l'inscription validée, détail de ce qu'il se passe :
+
+* Si crédit de la socitété générale, on mémorise que le fait que la personne ait demandé ce crédit (voir
+ `Trésorerie `_ section crédits de la société générale). Nécessairement, le club Kfet doit être rejoint.
+* Sinon, on crédite la note du montant demandé par le nouveau membre (avec comme description "Crédit TYPE (Inscription)"
+ où TYPE est le type de crédit), après avoir vérifié que le crédit est suffisant (on n'ouvre pas une note négative)
+* On adhère la personne au BDE, l'adhésion commence aujourd'hui. Il dispose d'un unique rôle : "Adhérent BDE",
+ lui octroyant un faible nombre de permissions de base, telles que la visualisation de son compte.
+* On adhère la personne au club Kfet si cela est demandé, l'adhésion commence aujourd'hui. Il dispose d'un unique rôle :
+ "Adhérent Kfet", lui octroyant un nombre un peu plus conséquent de permissions basiques, telles que la possibilité de
+ faire des transactions, d'accéder aux activités, au WEI, ...
+* Si le nouveau membre a indiqué avoir ouvert un compte à la société générale, alors les transactions sont invalidées,
+ la note n'est pas débitée (commence alors à 0 €).
+
+Par ailleurs, le BDE peut supprimer la demande d'inscription sans problème via un bouton dédié. Cette opération
+n'est pas réversible.
+
+L'utilisateur a enfin accès a sa note et peut faire des bêtises :)
+
+L'inscription au BDE et à la Kfet est indépendante de l'inscription au WEI. Voir `WEI `_ pour l'inscription WEI.
diff --git a/docs/apps/treasury.rst b/docs/apps/treasury.rst
new file mode 100644
index 00000000..23a1c0ff
--- /dev/null
+++ b/docs/apps/treasury.rst
@@ -0,0 +1,221 @@
+Application Trésorerie
+======================
+
+L'application de Trésorerie facilite la vie des trésorier, et sert d'interface de création de facture.
+Elle permet également le suivi des remises de chèques reçus par le BDE et des crédits de la Société générale.
+
+Factures
+--------
+
+Modèle des factures
+~~~~~~~~~~~~~~~~~~~
+
+Il est possible de créer des factures, qui seront enregistrées en base de données. Les différents attributs sont :
+
+* ``id`` : Le numéro de la facture
+* ``name`` : Le nom de la personne ou la raison sociale à qui est destinée la facture
+* ``address`` : L'adresse de cette personne ou raison sociale
+* ``bde`` : Le nom du fichier contenant le logo du BDE sous lequel a été éditée la facture. Ce champ ne peut pas être
+ modifié depuis la note, et vaut par défaut le logo du BDE en fonction (exemple : ``Saperlistpopette.png``)
+* ``date`` : Le jour d'émission de la facture (par défaut le jour même)
+* ``object`` : L'objet de la facture, le titre
+* ``description`` : La description de la facture
+* ``acquitted`` : Indique si la facture a déjà été acquittée ou non.
+
+Les factures contiennent également certaines valeurs hard-codées pour ne pas polluer la base de données, telle que
+la raison sociale du BDE, son adresse ainsi que ses coordonnées bancaires.
+
+Produits
+~~~~~~~~
+
+À chaque facture est associée plusieurs produits. Pour permettre cela, un modèle ``Product`` a été créé contenant 4 attributs :
+
+ * ``invoice`` : ``ForeignKey`` vers la facture associée au produit
+ * ``designation`` : Désignation du produit
+ * ``quantity`` : Quantité achetée
+ * ``amount`` : Prix unitaire (HT) du produit (peut être négatif si jamais il s'agit d'un rabais, d'un solde prépayé, ...)
+
+Pour ajouter des produits à une facture, cela se passe sur le même formulaire d'ajout/de modification de factures.
+Pour cela, on utilise un ``FormSet``, qui permet de gérer un nombre arbitraire de formulaires
+(chaque produit est un sous-formulaire).
+
+En en-tête, ce code HTML est généré automatiquement :
+
+.. code:: html
+
+ `` est le nombre de produits initialement. Cela permet d'indiquer au FormSet combien de formulaires
+il y a et combien il faut en gérer. La partie HTML de chaque produit ressemble à ceci :
+
+.. code:: html
+
+
+
+
+
+
+
+Où ``__prefix__`` est remplacé par le numéro de ligne et ```` l'identifiant de la facture
+(non renseigné si non encore créé). De cette manière, le FormSet sait associer chaque formulaire à ses données.
+On note la présence de deux champs cachés :
+
+ * ``product_set-__prefix__-invoice`` contient l'identifiant de la facture (si existant)
+ * ``product_set-__prefix__-id`` contient l'identifiant du produit en base de données (si existant, sinon 0)
+
+Deux boutons sont présents sur la page, pour ajouter et supprimer un produit. Cela a pour effet de mettre à jour
+les informations présentes dans les méta-données du formulaire présentées ci-dessus, et de copier une ligne vide
+(présentée ci-dessus) et de l'afficher en remplaçant ``__prefix__`` par les bonnes valeurs.
+
+Au moment de la sauvegarde du formulaire, on s'assure d'enregistrer tous les produits associés.
+
+Génération
+~~~~~~~~~~
+
+Les factures peuvent s'exporter au format PDF (là est tout leur intérêt). Pour cela, on utilise le template LaTeX
+présent à l'adresse suivante :
+`/templates/treasury/invoice_sample.tex `_
+
+On le remplit avec les données de la facture et les données du BDE, hard-codées. On copie le template rempli dans un
+ficher tex dans un dossier temporaire. On fait ensuite 2 appels à ``pdflatex`` pour générer la facture au format PDF.
+Les deux appels sont nécessaires, il y a besoin d'un double rendu. Ensuite, le PDF est envoyé à l'utilisateur et on
+supprime les données temporaires.
+
+On remarque que les PDF sont générés à la volée et ne sont pas sauvegardés. Niveau performances, cela prend du temps
+au plus 2-3 secondes), mais cela n'est pas un problème car on ne génère pas des factures fréquemment. Niveau fiabilité
+des données, il faut s'assurer que les données hard-codées ne changent pas, et si elles sont amenées à changer
+(pour cause de déménagement), il faudra s'assurer que cela n'impacte pas les anciennes factures, en ajoutant par
+exemple un champ ``old`` (ou ``kchan``) pour savoir s'il s'agit d'une nouvelle ou d'une ancienne facture.
+
+Remises de chèques
+------------------
+
+L'application trésorerie permet aussi de gérer les remises de chèques. En réalité, elle permet de gérer également des
+remises de crédit par carte bancaire, virement ou espèces, mais cela n'étant pas utilisé, ces types de transactions
+aparaîtront comme non supportées.
+
+Différents modèles
+~~~~~~~~~~~~~~~~~~
+
+Types de remises
+^^^^^^^^^^^^^^^^
+
+Comme indiqué ci-dessus, tous les types de remises ne sont pas supportés. Pour cela, on passe par un modèle
+``RemittanceType`` qui contient uniquement un champ ``OneToOneField`` vers un objet ``NoteSpecial``.
+On peut alors voir ``RemittanceType`` comme un sous-ensemble des notes spéciales, qui correspond aux types de remises
+supportées. Par défaut, seule la note ``Chèque`` est supportée (après chargement des données initiales).
+
+L'intérêt de ce genre de procédé plutôt que d'ajouter un booléen dans le modèle ``NoteSpecial`` est d'empêcher toute
+dépendance de l'application ``treasury`` dans l'application ``note``, la rendant plus externe.
+
+Proxys vers transactions de crédit
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+De la même manière que les types de remise, ce modèle, appelé ``SpecialTransactionProxy``, n'existe que pour rendre
+l'application ``treasury`` externe et de ne pas surcharger le modèle ``SpecialTransaction``.
+
+Ce modèle contient deux attributs :
+
+* ``transaction`` : ``OneToOneField`` vers ``SpecialTransaction``
+* ``remittance`` : ``ForeignKey`` vers ``Remittance`` (voir ci-dessous), remise associée à cette transaction
+
+À chaque fois qu'une transaction spéciale d'un type accepté est créée, un proxy est ajouté automatiquement par le biais
+d'un signal. De plus, à chaque fois que le serveur web démarre, les vieilles transactions d'un bon type sans proxy s'en
+voient dotées d'un.
+
+Remises
+^^^^^^^
+
+Les modèles des remises contiennent les attributs suivants :
+
+* ``remittance_type`` : ``ForeignKey`` vers ``RemittanceType`` : type de remise (chèque, carte bancaire, virement, espèces)
+* ``date`` : date et heure d'ouverture de la remise (``DateTimeField``)
+* ``comment`` : commentaire sur la remise, description
+* ``closed`` : booléen indiquant si la remise est close ou non
+
+Ce modèle contient des propriétés supplémentaires :
+
+* ``transactions`` : ``QuerySet``, transactions liées à la remise
+* ``count`` : nombre de transactions liées
+* ``amount`` : somme totale des transactions liées
+
+Relations
+~~~~~~~~~
+
+* Toute transaction qui n'est pas attachée à une remise d'un bon type peut être attachée à une remise. Cela se passe
+ par le biais d'un formulaire, où le trésorier peut vérifier et corriger au besoin nom, prénom, banque émettrice et montant.
+
+* Toute transaction attachée à une remise encore ouverte peut être retirée.
+* Pour clore une remise, il faut au moins 1 transaction associée.
+* Il n'est plus possible de modifier de quelque manière que ce soit une remise close, que ce soit en modifiant le
+ commentaire, en ajoutant ou en supprimant une transaction attachée.
+* Il n'est pas possible de modifier le type d'une remise. De plus, il n'est pas possible d'ajouter une transaction à
+ une remise si elle n'est pas du bon type.
+
+Crédits de la Société générale
+------------------------------
+
+La note permet la gestion des crédits de la Société générale, conformément au partenariat établi entre la banque et le BDE.
+
+Modèle
+~~~~~~
+
+Cette sous-application dispose d'un unique modèle "SogeCredit" avec les champs suivant :
+
+* ``user`` : ``OneToOneField`` vers ``User``, utilisateur associé à ce crédit (relation ``OneToOne`` car chaque
+ utilisateur ne peut bénéficier qu'une seule fois d'un crédit de la Société générale)
+* ``transactions`` : ``ManyToManyField`` vers ``MembershipTransaction``, liste des transactions d'adhésion associées
+ à ce crédit, généralement adhésion BDE+Kfet+WEI même si cela n'est pas restreint
+* ``credit_transaction`` : ``OneToOneField`` vers ``SpecialTransaction``, peut être nulle, transaction de crédit de la
+ Société générale vers la note de l'utilisateur si celui-ci a été validé. C'est d'ailleurs le témoin
+ de validation du crédit.
+
+On sait qu'un utilisateur a déjà demandé un crédit de la Société générale s'il existe un crédit associé à cet
+utilisateur avec une transaction associée. Par ailleurs, le modèle ``Profile`` contient une propriété ``soge`` qui
+traduit exactement ceci, et qui vaut ``False`` si jamais l'application Trésorerie n'est pas chargée.
+
+Si jamais l'utilisateur n'a pas encore demandé de crédit de la Société générale (ou que celui-ci n'est pas encore validé),
+l'utilisateur peut demander un tel crédit lors de son adhésion BDE, de sa réadhésion BDE ou de son inscription au WEI.
+Dans les deux premiers cas, il est invité à jumeler avec une nouvelle adhésion Kfet (merci de d'abord se réadhérer au
+BDE avant la Kfet dans ce cas).
+
+Lorsqu'une telle demande est faite, l'adhésion est créée avec une transaction d'adhésion invalide. Cela implique que
+la note source n'est pas débitée et la note destination n'est pas créditée.
+
+Sur son interface, le trésorier peut récupérer les crédits de Société générale invalides. Deux options s'offrent à lui :
+
+* Supprimer la demande. Dans ce cas, les transactions vont être validées, la note de l'utilisateur sera débité, les
+ clubs seront crédités. Puisque la demande sera supprimée, l'utilisateur pourra à nouveau à l'avenir déclarer avoir
+ ouvert un compte à la Société générale. Cette option est utile dans le cas où l'utilisateur est un boulet (ou pas,
+ pour d'autres raisons) et a déclaré vouloir ouvrir un compte à la Société générale sans ne rien faire.
+ Cette action est irréversible, et n'est pas possible si la note de l'utilisateur n'a pas un solde suffisant.
+
+* Valider la demande. Dans ce cas, un crédit de la note "Virements bancaires" vers la note de l'utilisateur sera créé,
+ la transaction sera liée à la demande via le champ ``credit_note`` (et donc la demande déclarée valide), et toutes les
+ transactions d'adhésion seront déclarées valides.
+
+* Demander à un respo info s'il y a un problème pour le régler avant de faire des bêtises. Je l'admets, ça fait trois options.
+
+La validité d'une transaction d'adhésion n'a aucune influence sur l'adhésion elle-même. Toutefois, cela se remarque rapidement ...
+
+.. image:: /_static/img/treasury_validate_sogecredit.png
+
+Exemple de validation de crédit Société générale d'un étudiant non payé "toto2" s'étant inscrit au BDE, à la Kfet et au WEI.
+
+Diagramme des modèles
+---------------------
+
+.. image:: /_static/img/graphs/treasury.svg
+ :alt: Graphe de l'application trésorerie
\ No newline at end of file
diff --git a/docs/apps/wei.rst b/docs/apps/wei.rst
new file mode 100644
index 00000000..892c0a87
--- /dev/null
+++ b/docs/apps/wei.rst
@@ -0,0 +1,332 @@
+WEI
+===
+
+Cette application gère toute la phase d'inscription au WEI.
+
+Modèles
+-------
+
+WEIClub
+~~~~~~~
+
+Le modèle ``WEIClub`` hérite de ``Club`` et contient toutes les informations d'un WEI.
+
+* ``year`` : ``PositiveIntegerField`` unique, année du WEI.
+* ``date_start`` : ``DateField``, date de début du WEI.
+* ``date_end`` : ``DateField``, date de fin du WEI.
+
+Champs hérités de ``Club`` de l'application ``member`` :
+
+* ``parent_club`` : ``ForeignKey(Club)``. Ce champ vaut toujours ``Kfet`` dans le cas d'un WEI : on doit être membre du
+ club Kfet pour participer au WEI.
+* ``email`` : ``EmailField``, adresse e-mail sur laquelle contacter les gérants du WEI.
+* ``membership_start`` : ``DateField``, date à partir de laquelle il est possible de s'inscrire au WEI.
+* ``membership_end`` : ``DateField``, date de fin d'adhésion possible au WEI.
+* ``membership_duration`` : ``PositiveIntegerField``, inutilisé dans le cas d'un WEI, vaut ``None``.
+* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un élève normalien
+ (donc rémunéré) puisse adhérer.
+* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un étudiant
+ normalien (donc non rémunéré) puisse adhérer.
+* ``name`` : ``CharField``, nom du WEI.
+* ``require_memberships`` : ``BooleanField``, vaut toujours ``True`` pour le WEI.
+
+Bus
+~~~
+
+Contient les informations sur un bus allant au WEI.
+
+* ``wei`` : ``ForeignKey(WEIClub)``, WEI auquel ce bus est rattaché.
+* ``name`` : ``CharField``, nom du bus. Le champ est unique pour le WEI attaché.
+* ``description`` : ``TextField``, description textuelle de l'ambiance du bus.
+* ``information_json`` : ``TextField``, diverses informations non publiques qui permettent d'indiquer divers paramètres
+ pouvant varier selon les années permettant l'attribution des bus aux 1A.
+
+Il est souhaitable de créer chaque année un bus "Staff" (non accessible aux 1A bien évidemment) pour les GC WEI qui ne
+monteraient pas dans un bus.
+
+BusTeam
+~~~~~~~
+
+Contient les informations d'une équipe WEI.
+
+* ``wei`` : ``ForeignKey(WEIClub)``, WEI auquel cette équipe est rattachée.
+* ``name`` : ``CharField``, nom de l'équipe.
+* ``color`` : ``PositiveIntegerField``, entier entre 0 et 16777215 = 0xFFFFFF représentant la couleur du T-Shirt.
+ La donnée se rentre en hexadécimal via un sélecteur de couleur. Cette information est purement cosmétique et n'est
+ utilisée nulle part.
+* ``description`` : ``TextField``, description de l'équipe.
+
+WEIRole
+~~~~~~~
+
+Ce modèle hérité de ``Role``, ne contient qu'un champ ``name`` (``CharField``), le nom du rôle. Ce modèle ne permet
+que de dissocier les rôles propres au WEI des rôles s'appliquant pour n'importe quel club.
+
+WEIRegistration
+~~~~~~~~~~~~~~~
+
+Inscription au WEI, contenant les informations avant validation. Ce modèle est créé dès lors que quelqu'un se pré-inscrit au WEI.
+
+* ``user`` : ``ForeignKey(User)``, utilisateur qui s'est pré-inscrit. Ce champ est unique avec ``wei``.
+* ``wei`` : ``ForeignKey(WEIClub)``, le WEI auquel l'utilisateur s'est pré-inscrit. Ce champ est unique avec ``user``.
+* ``soge_credit`` : ``BooleanField``, indique si l'utilisateur a déclaré vouloir ouvrir un compte à la Société générale.
+* ``caution_check`` : ``BooleanField``, indique si l'utilisateur (en 2ème année ou plus) a bien remis son chèque de
+ caution auprès de la trésorerie.
+* ``birth_date`` : ``DateField``, date de naissance de l'utilisateur.
+* ``gender`` : ``CharField`` parmi ``male`` (Homme), ``female`` (Femme), ``non binary`` (Non binaire), genre de la personne.
+* ``health_issues`` : ``TextField``, problèmes de santé déclarés par l'utilisateur.
+* ``emergency_contact_name`` : ``CharField``, nom du contact en cas d'urgence.
+* ``emergency_contact_phone`` : ``CharField``, numéro de téléphone du contact en cas d'urgence.
+* ``ml_events_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
+ événements du BDE (1A uniquement)
+* ``ml_art_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
+ actualités du BDA (1A uniquement)
+* ``ml_sport_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
+ actualités du BDS (1A uniquement)
+* ``first_year`` : ``BooleanField``, indique si l'inscription est d'un 1A ou non. Non modifiable par n'importe qui.
+* ``information_json`` : ``TextField`` non modifiable manuellement par n'importe qui stockant les informations du
+ questionnaire d'inscription au WEI pour les 1A, et stocke les demandes faites par un 2A+ concerant bus, équipes et rôles.
+ On utilise un ``TextField`` contenant des données au format JSON pour permettre de la modularité au fil des années,
+ sans avoir à tout casser à chaque fois.
+
+WEIMembership
+~~~~~~~~~~~~~
+
+Ce modèle hérite de ``Membership`` et contient les informations d'une adhésion au WEI.
+
+* ``bus`` : ``ForeignKey(Bus)``, bus dans lequel se trouve l'utilisateur.
+* ``team`` : ``ForeignKey(BusTeam)`` pouvant être nulle (pour les chefs de bus et électrons libres), équipe dans laquelle
+ se trouve l'utilisateur.
+* ``registration`` : ``OneToOneField(WEIRegistration)``, informations de la pré-inscription.
+
+Champs hérités du modèle ``Membership`` :
+
+* ``club`` : ``ForeignKey(Club)``, club lié à l'adhésion. Doit être un ``WEIClub``.
+* ``user`` : ``ForeignKey(User)``, utilisateur adhéré.
+* ``date_start`` : ``DateField``, date de début d'adhésion.
+* ``date_end`` : ``DateField``, date de fin d'adhésion.
+* ``fee`` : ``PositiveIntegerField``, montant de la cotisation payée.
+* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent. Les rôles doivent être des ``WEIRole``.
+
+Graphe des modèles
+~~~~~~~~~~~~~~~~~~
+
+Pour une meilleure compréhension, le graphe des modèles de l'application ``member`` ont été ajoutés au schéma.
+
+.. image:: /_static/img/graphs/wei.svg
+ :alt: Graphe des modèles de l'application WEI
+
+Fonctionnement
+--------------
+
+Création d'un WEI
+~~~~~~~~~~~~~~~~~
+
+Seul un respo info peut créer un WEI. Pour cela, se rendre dans l'onglet WEI, puis "Liste des WEI" et enfin
+"Créer un WEI". Diverses informations sont demandées, comme le nom du WEI, l'adresse mail de contact, l'année du WEI
+(doit être unique), les dates de début et de fin, et les dates pendant lesquelles les utilisateurs peuvent s'inscrire.
+
+Don des droits à un GC WEI
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Le GC WEI peut gérer tout ce qui a un rapport avec le WEI. Il ne peut cependant pas créer le WEI, ce privilège est
+réservé au respo info. Pour avoir ses droits, le GC WEI doit s'inscrire au WEI avec le rôle GC WEI, et donc payer
+en premier sa cotisation. C'est donc au respo info de créer l'adhésion du GC WEI. Voir ci-dessous pour l'inscription au WEI.
+
+S'inscrire au WEI
+~~~~~~~~~~~~~~~~~
+
+N'importe quel utilisateur peut s'auto-inscrire au WEI, lorsque les dates d'adhésion le permettent. Ceux qui se sont
+déjà inscrits peuvent également inscrire un 1A. Seuls les GC WEI et les respo info peuvent inscrire un autre 2A+.
+
+À tout moment, tant que le WEI n'est pas passé, l'inscription peut être modifiée, même après validation.
+
+Inscription d'un 2A+
+^^^^^^^^^^^^^^^^^^^^
+
+Comme indiqué, les 2A+ sont assez autonomes dans leur inscription au WEI. Ils remplissent le questionnaire et sont
+ensuite pré-inscrits. Le questionnaire se compose de plusieurs champs (voir WEIRegistration) :
+
+* Est-ce que l'utilisateur a déclaré avoir ouvert un compte à la Société générale ? (Option disponible uniquemement
+ si cela n'a pas été fait une année avant)
+* Date de naissance
+* Genre (Homme/Femme/Non-binaire)
+* Problèmes de santé
+* Nom du contact en cas d'urgence
+* Numéro du contact en cas d'urgence
+* Bus préférés (choix multiple, utile pour les électrons libres)
+* Équipes préférées (choix multiple éventuellement vide, vide pour les chefs de bus/staff)
+* Rôles souhaités
+
+Les trois derniers champs n'ont aucun caractère définitif et sont simplement là en suggestion pour le GC WEI qui
+validera l'inscription. C'est utile si on hésite entre plusieurs bus.
+
+L'inscription est ensuite créée, le GC WEI devra ensuite la valider (voir plus bas).
+
+Inscription d'un 1A
+^^^^^^^^^^^^^^^^^^^
+
+N'importe quelle personne déjà inscrite au WEI peut inscrire un 1A. Le formulaire 1A est assez peu différent du formulaire 2A+ :
+
+* Est-ce que l'utilisateur a déclaré avoir ouvert un compte à la Société générale ?
+* Date de naissance
+* Genre (Homme/Femme/Non-binaire)
+* Problèmes de santé
+* Nom du contact en cas d'urgence
+* Numéro du contact en cas d'urgence
+* S'inscrire à la ML événements
+* S'inscrire à la ML BDA
+* S'inscrire à la ML BDS
+
+Le 1A ne peut donc pas choisir de son bus et de son équipe, et peut s'inscrire aux listes de diffusion.
+Il y a néanmoins une différence majeure : une fois le formulaire rempli, un questionnaire se lance.
+Ce questionnaire peut varier au fil des années (voir section Questionnaire), et contient divers formulaires de collecte
+de données qui serviront à déterminer quel est le meilleur bus pour ce nouvel utilisateur.
+
+Questionnaire 1A
+^^^^^^^^^^^^^^^^
+
+Le questionnaire 1A permet de poser des questions aux 1A lors de leur inscription au WEI afin de déterminer quel serait
+le meilleur bus pour eux. Un algorithme attribue ensuite à chaque 1A le bus sélectionné.
+
+Afin de permettre de la modularité et de s'adapter aux changements au fil des années, il n'y a pas de modèle dédié au
+sondage. On sauvegarde alors les données du sondage sous la forme d'un dictionnaire enregistré au format JSON
+dans le champ ``information_json`` du modèle ``WEIRegistration``. Ce champ est modifiable manuellement uniquement par
+les respos info et les GC WEI.
+
+Je veux changer d'algorithme de répartition, que faire ?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+Cette section est plus technique et s'adresse surtout aux respos info en cours de mandat.
+
+Première règle : on ne supprime rien (sauf si vraiment c'est du mauvais boulot). En prenant exemple sur des fichiers déjà existant tels que ``apps/wei/forms/surveys/wei2020.py``, créer un nouveau fichier ``apps/wei/forms/surveys/wei20XY.py``. Ce fichier doit inclure les éléments suivants :
+
+WEISurvey
+"""""""""
+
+Une classe héritant de ``wei.forms.surveys.base.WEISurvey``, comportant les éléments suivants :
+
+* Une fonction ``get_year(cls)`` indiquant l'année du WEI liée au sondage
+* Une fonction ``get_survey_information_class(cls)`` indiquant la classe héritant de
+ ``wei.forms.surveys.base.WEISurveyInformation`` contenant les données du sondage (voir plus bas)
+* Une fonction ``get_algorithm_class(cls)`` indiquant la classe héritant de
+ ``wei.forms.surveys.base.WEISurveyAlgorithm`` contenant l'algorithme de répartition (voir plus bas)
+* Une fonction ``get_form_class(self)`` qui indique la classe du formulaire Django à remplir. Cette classe peut dépendre
+ de l'état actuel du sondage.
+* Une fonction ``update_form(self, form)``, optionnelle, appelée lorsqu'un formulaire dont la classe est spécifiée via
+ la fonction ``get_form_class``, et permet d'opérer sur le formulaire si besoin.
+* Une fonction ``form_valid(self, form)`` qui indique quoi faire lorsque le formulaire est rempli. Cette fonction peut
+ bien sûr dépendre de l'état actuel du sondage.
+* Une fonction ``is_complete(self)`` devant renvoyer un booléen indiquant si le sondage est complet ou non.
+
+Naturellement, il est implicite qu'une fonction ayant pour premier argument ``cls`` doit être annotée par ``@classmethod``.
+Nativement, la classe ``WEISurvey`` comprend les informations suivantes :
+
+* ``registration``, le modèle ``WEIRegistration`` de l'utilisateur qui remplit le questionnaire
+* ``information``, instance de ``WEISurveyInformation``, contient les données du questionnaire en cours de remplissage.
+* ``get_wei(cls)``, renvoie le WEI correspondant à l'année du sondage.
+* ``save(self)``, enregistre les informations du sondage dans l'objet ``registration`` associé, qui est ensuite
+ enregistré en base de données.
+* ``select_bus(self, bus)``, choisit le bus ``bus`` comme bus préféré. Cela à pour effet de remplir les champs
+ ``selected_bus_pk`` et ``selected_bus_name`` par les identifiant et nom du bus, et ``valid`` à ``True``.
+
+Pour information, ``WEISurvey.__init__`` prend comme paramètre l'inscription ``registration``, et récupère les
+informations du sondage converties en dictionnaire Python puis en objet ``WEISurveyInformation``.
+
+WEISurveyInformation
+""""""""""""""""""""
+
+Une classe héritant de ``wei.forms.surveys.base.WEISurveyInformation``, comportant les informations brutes du sondage.
+Le champ ``information_json`` de ``WEIRegistration`` est traduit en dictionnaire Python depuis JSON, puis les différents
+champs de WEISurveyInformation sont mis à jour depuis ce dictionnaire. Il n'y a rien de supplémentaire à ajouter, tout
+est déjà géré.
+
+Ainsi, plutôt que de modifier laborieusement le champ JSON, préférez utiliser cette classe. Attention : pour des soucis
+de traduction facile, merci de n'utiliser que des objets primitifs (nombres, chaînes de caractère, booléens, listes,
+dictionnaires simples). Les instances de modèle sont à proscrire, préférez stocker l'identifiant et créer une fonction
+qui récupère l'instance à partir de l'identifiant.
+
+Attention, 3 noms sont réservés : ``selected_bus_pk``, ``selected_bus_name`` et ``valid``, qui représentent la sortie
+de l'algorithme de répartition.
+
+À noter que l'interface de validation des inscriptions affiche les données brutes du sondage.
+
+WEIBusInformation
+"""""""""""""""""
+
+Une classe héritant de ``wei.forms.surveys.base.WEIBusInformation``, qui contient les informations sur un bus,
+de la même manière que ``WEISurveyInformation`` contient les informations d'un sondage. Le fonctionnement est le même :
+on récupère le champ ``information_json`` du modèle ``Bus`` qu'on convertit en dictionnaire puis en objet Python.
+Cet objet est en lecture uniquement, on modifie à la main les paramètres d'un bus.
+
+Le champ ``bus`` est fourni.
+
+WEISurveyAlgorithm
+""""""""""""""""""
+
+Une classe héritant de ``wei.forms.surveys.base.WEISurveyAlgorithm``, qui contient 3 fonctions :
+
+* ``get_survey_class(cls)``, qui renvoie la classe du ``WEISurvey`` associée à l'algorithme.
+* ``get_bus_information_class(cls)`` qui renvoie la classe du ``WEIBusInformation`` décrivant les informations d'
+* ``run_algorithm(self)``, la fonction importante. Cette fonction n'est supposée n'être exécutée qu'une seule fois
+ par WEI, et a pour cahier des charges de prendre chaque sondage d'un 1A et d'appeler la fonction ``WEISurvey.select_bus(bus)``,
+ en décidant convenablement de quel bus le membre doit prendre. C'est bien sûr la fonction la plus complexe à mettre en oeuvre.
+ Tout est permis tant qu'à la fin tout le monde a bien son bus.
+
+Trois fonctions sont implémentées nativement :
+
+* ``get_registrations(cls)``, renvoie un ``QuerySSet`` vers l'ensemble des inscriptions au WEI concerné des 1A.
+* ``get_buses(cls)``, renvoie l'ensemble des bus du WEI concerné.
+* ``get_bus_information(cls, bus)``, renvoie l'objet ``WEIBusInformation`` instancié avec les informations fournies
+ par le champ ``information_json`` de ``bus``.
+
+
+La dernière chose à faire est dans le fichier ``apps/wei/forms/surveys/__init__.py``, où la classe ``CurrentSurvey``
+est à mettre à jour. Il n'y a rien d'autre à changer, tout le reste est normalement géré pour qu'il n'y ait pas nécessité
+d'y toucher.
+
+Le lancement de l'algorithme se fait en ligne de commande, via la commande ``python manage.py wei_algorithm``. Elle a
+pour unique effet d'appeler la fonction ``run_algorithm`` décrite plus tôt. Une fois cela fait, vous aurez noté qu'il
+n'a pas été évoqué d'adhésion. L'adhésion est ensuite manuelle, l'algorithme ne fournit qu'une suggestion.
+
+Cette structure, complexe mais raisonnable, permet de gérer plus ou moins proprement la répartition des 1A,
+en limitant très fortement le hard code. Ami nouveau développeur, merci de bien penser à la propreté du code :)
+En particulier, on évitera de mentionner dans le code le nom des bus, et profiter du champ ``information_json``
+présent dans le modèle ``Bus``.
+
+Valider les inscriptions
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Cette partie est moins technique.
+
+Une fois la pré-inscription faite, elle doit être validée par le BDE, afin de procéder au paiement. Le GC WEI a accès à
+la liste des inscriptions non validées, soit sur la page de détails du WEI, soit sur un tableau plus large avec filtre.
+Une inscription non validée peut soit être validée, soit supprimée (la suppression est irréversible).
+
+Lorsque le GC WEI veut valider une inscription, il a accès au récapitulatif de l'inscription ainsi qu'aux informations
+personnelles de l'utilisateur. Il lui est proposé de les modifier si besoin (du moins les informations liées au WEI,
+pas les informations personnelles). Il a enfin accès aux résultats du sondage et la sortie de l'algorithme s'il s'agit
+d'un 1A, aux préférences d'un 2A+. Avant de valider, le GC WEI doit sélectionner un bus, éventuellement une équipe
+et un rôle. Si c'est un 1A et que l'algorithme a tourné, ou si c'est un 2A+ qui n'a fait qu'un seul choix de bus,
+d'équipe, de rôles, les champs sont automatiquement pré-remplis.
+
+Quelques restrictions cependant :
+
+* Si c'est un 2A+, le chèque de caution doit être déclaré déposé
+* Si l'inscription se fait via la Société générale, un message expliquant la situation apparaît : la transaction de
+ paiement sera créée mais invalidée, les trésoriers devront confirmer plus tard sur leur interface que le compte
+ à la Société générale a bien été créé avant de valider la transaction (voir `Trésorerie `_ section
+ Crédit de la Société générale).
+* Dans le cas contraire, l'utilisateur doit avoir le solde nécessaire sur sa note avant de pouvoir adhérer.
+* L'utilisateur doit enfin être membre du club Kfet. Un lien est présent pour le faire adhérer ou réadhérer selon le cas.
+
+Si tout est bon, le GC WEI peut valider. L'utilisateur a bien payé son WEI, et son interface est un peu plus grande.
+Il peut toujours changer ses paramètres au besoin. Un 1A ne voit rien de plus avant la fin du WEI.
+
+Un adhérent WEI non 1A a accès à la liste des bus, des équipes et de leur descriptions. Les chefs de bus peuvent gérer
+les bus et leurs équipes. Les chefs d'équipe peuvent gérer leurs équipes. Cela inclut avoir accès à la liste des membres
+de ce bus / de cette équipe.
+
+Un export au format PDF de la liste des membres *visibles* est disponible pour chacun.
+
+Bon WEI à tous !
diff --git a/docs/index.rst b/docs/index.rst
index 9e5048d3..766053aa 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,20 +1,14 @@
-.. Note Kfet 2020 documentation master file, created by
- sphinx-quickstart on Thu Nov 26 00:58:58 2020.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
+Documentation de la Note Kfet 2020
+==================================
-Welcome to Note Kfet 2020's documentation!
-==========================================
+
+Bienvenue sur le Wiki de la NoteKfet2020. Ce wiki est plutot orienté vers un public de développeur, qui souhaitent
+contribuer au développement, mais expliquent également aux plus curieux comment fonctionne la NoteKfet2020 sous le capot.
+
+Des informations complémentaires sont également disponibles sur le `Wiki Crans