# UPTech PFE Book 2027 > **How to use this file.** This is the complete UPTech PFE Book 2027 in Markdown: everything on https://www.uptech.com.tn/pfe-2027.html, plus more details for each project (scope, go-live milestones, evaluation, reading). It is kept short so it works with free AI plans. No PDF needed: load this file into your AI assistant and ask it questions, for example: > > - *Here is the UPTech PFE Book 2027 and my CV. Which 3 projects fit my profile best? Explain why, and what I should learn first.* > - *Explain project REF-... in simple words: the problem, what I would build, and how the result is evaluated.* > - *Make me a 4-week preparation plan for project REF-..., based on its key tasks and tools.* > - *Ask me 5 interview questions about project REF-..., one at a time, and give me feedback on my answers.* > > Use AI to understand the projects and to prepare. Write your application answers yourself, and tell us in the form how you used AI. > > **Apply only through the web form, before 25 November 2026, 23:59 (Tunis time):** https://forms.gle/LuaMtB8aXrd8t6VW8 > > Version of 2026-11-11 · 22 projects · https://www.uptech.com.tn/UPTech-PFE-Book-2027.md ## About UPTech Founded in 2019, UPTech helps businesses work smarter with integrated technology. Our expertise covers software development, ERP integration, cloud and DevOps, RFID systems and IT operations management. Our mission: turn operational complexity into simplicity. Our vision: predictive, data-driven operations that create real value for our clients. ## What we offer - **Mentoring by experts** of the field, every week, on a real UPTech product or platform. - **A project that goes live** and that you measure on real usage: a strong case for your CV and your defence. - **Hybrid work:** you work remotely and come to the office when your project needs it. - **Access to the UPTech reference library** (books, articles, standards) and to our self-hosted lab. - **A motivation bonus at the end of the internship may be offered**, based on results: a training course, a certification or a subscription. - **AI-friendly projects:** all our projects welcome AI tools, and we onboard you so you use AI confidently and get the best results from it. - The internship is **unpaid**. ## Our culture and what we expect - **We are looking for serious people.** We mentor you closely and help you at every step, and in return we expect a real outcome. If you join, commit to your project from day one. - **Documentation is one of our pillars.** We talk a lot (chat, meetings, reviews), but what really counts is what is written: every decision, every sprint and every result goes into your repository. - **Your report starts in week 1, in LaTeX.** LaTeX is the only format we accept. In your first week you set up your LaTeX report project in your repository, and it grows sprint after sprint with your project. - **Less is more.** We are minimalists: as few tools as possible, as little process as needed, no bottlenecks. In return, we expect the process we do have to be followed fully. - **Ask, ask, ask.** We love questions. Never hesitate and never stay stuck: you and all your questions are very welcome here. - **Be honest and clear.** In your application, your mission and your interview, tell us what you really know, what you did yourself and how you used AI. Our goal is to place you on the project that best fits your profile and your career, and that only works with honest answers. ## How we work with interns - **A clear plan, from 3 to 6 months.** Each project has a core plan of 8 two-week sprints. Shorter internships use a reduced plan; longer ones go further once the core is done. - **Clear scope and Definition of Done.** In your first two weeks you sign a project charter: what is in scope, what is out, and when the project is done. The expected result does not change during the internship; new ideas wait until the charter is closed. - **Deliver every sprint.** At the end of each sprint you deliver your code and documentation in your dedicated GitLab repository (merge to main, sprint tag, sprint note) and show it in a short review. - **Your project goes live.** A first version runs in production after four weeks, real users pilot it after eight weeks, and it is in production after twelve weeks. You then run it and measure it on real usage. - **Work alone or in a pair.** Your project never depends on another project. Some projects can take a pair: each student owns a clear part, in the same repository, with code reviews from each other. - **Tools are a starting proposal.** The tools listed for each project can change: you compare options in your first sprint and the final stack is agreed in your project charter. - **Learn from the best references.** You get a reading list from the UPTech library (design patterns, architecture, best practices of your field) and apply it in your work. - **You continue real work and measure it.** Every project starts from an existing UPTech product or platform, and your report includes an evaluation chapter. - **100 % self-hosted.** Everything runs on UPTech's own infrastructure, including the AI models we use in our products: no cloud services. You test locally with **Docker** and deploy to **Kubernetes** for staging and production. ### Duration | Internship length | Plan | |---|---| | 3 months | 6 sprints: pilot after sprint 3, production after sprint 5, last sprint for support, evaluation and handover. The charter moves the last build items to the backlog | | 4 months | the core plan of 8 sprints as written in the project | | 5–6 months | the core plan, charter closure after 4 months, then backlog items, longer production support and a deeper evaluation | ### Typical calendar (4-month core plan, start in February 2027) | Sprint | Weeks | Content | |---|---|---| | 1 | 1–2 | onboarding, reading, state of the art, **LaTeX report project set up**, **project charter signed** | | 2 | 3–4 | design, **first version in production** (no users yet) | | 3 | 5–6 | build | | 4 | 7–8 | build · **pilot with real users** · mid-term review | | 5 | 9–10 | build | | 6 | 11–12 | build · **production go-live** · feature freeze | | 7 | 13–14 | production support + evaluation on real usage | | 8 | 15–16 | hardening, report, handover | | Closure | 17 | final demo, handover to the owner, charter closure | ## Delivery rules (apply to every project) 1. **Charter in sprint 1.** Scope (in / out), deliverables per sprint, Definition of Done, evaluation plan and risks are written in `docs/charter.md` and frozen. 2. **No change to the expected result.** New ideas go to `docs/backlog-after-charter.md` and are built only after the charter is closed. A real blocker can only be handled by swapping work of the same size, never by adding work. 3. **Delivery every sprint, Friday 17:00**, in your GitLab repository: code merged to `main` through merge requests with CI green, a tag `sprint-N`, a sprint note (planned / done / not done / next), updated documentation and the report chapter of the sprint in your LaTeX report project. 4. **General Definition of Done** for every deliverable: merged through a reviewed merge request, CI green, runs from the repository with one documented command, automated tests, no secrets in the repository, documentation updated, design decisions name the pattern or practice used and its reference, deployed by the pipeline, shown in the sprint review. 5. **Project closure:** live at the level stated in the project, handed over to its owner, results reproducible from the repository, release `v1.0`, runbook and handover notes, report with an Evaluation chapter and a "Best practices applied" section, 3-minute demo video. 6. **Go-live checklist** for every production release: security scan, load test within the performance budget, monitoring and alerts, tested backup and rollback, runbook and user guide, data approval when needed, approved change ticket. 7. **Safe by design:** you test locally with Docker and deploy only through GitLab CI and Argo CD to Kubernetes (staging, then production), never directly to production; new features sit behind feature flags; releases are gradual with automatic rollback. 8. **Reading library:** read the core references of your track in sprint 1, keep a reading log in every sprint note, and present one reference in the reviews of sprints 2, 4 and 6. 9. **Pairs:** one joint charter that gives every item to student A or B, one repository, the same sprints, a review of every merge request by the other student, and one report each. 10. **Standard repository:** README, `docs/charter.md`, `docs/sprints/`, `docs/architecture.md`, `docs/runbook.md`, `docs/handover.md`, `docs/backlog-after-charter.md`, `docs/change-requests.md`, `docs/report/` (LaTeX report project, set up in week 1), `eval/`. ## Our self-hosted platform Our core stack: **Docker** (local tests) · **Kubernetes** on VMware (staging and production) · **GitLab CI** and **Argo CD** (GitOps) · **Keycloak** · **Vault** · **Spring Boot** microservices and **Angular** · **MySQL** / **PostgreSQL** · **RabbitMQ** · **Prometheus / Grafana** · a shared **local LLM** server · our **ITSM** platform. Less is more: each project uses only what it really needs from this stack. ## Our 2027 projects ### UPTech AIOps Lab — Integrated IT Operations Platform #### REF-AIOPS01 — Knowledge-grounded incident diagnosis (RAG evaluation) **Description:** When an incident is opened, technicians lose time searching old tickets and wiki pages. Build and *evaluate* an assistant that retrieves the most useful past tickets, knowledge articles and service-topology context, and proposes a diagnosis with citations. You will compare plain RAG with a hybrid retrieval that also uses topology and article reliability, on a labelled set of incidents. **Key tasks:** hybrid retrieval (BM25 + embeddings + reranker) · topology-aware scoring · LLM diagnosis with citation check · evaluation set and benchmark (Recall@k, MRR, grounded accuracy, faithfulness, latency, cost) **Tools (preliminary proposal):** Python, PostgreSQL/pgvector, sentence-transformers, Ollama (local LLMs), ITSM, Wiki.js **Profile:** Engineering or Master: AI / Data Science / Software Engineering. Interest in NLP and evaluation. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Corpus: UPTech's ITOps reference corpus; anonymised export of UPTech's ITSM tickets and knowledge base (approved); Evaluation set: 200 incidents with known root cause and resolution article (time-ordered split); Retrieval: BM25, dense (MiniLM), hybrid + reranker (baseline B3), fused score with topology distance and reliability (Fused retrieval score, Knowledge reliability with forgetting); Diagnosis with one local LLM (3B–8B) and one second local LLM for comparison; citations limited to retrieved items, checked automatically; Small web demo (FastAPI page or ITSM link) showing the top-3 suggestions with citations - **Out of scope:** production deployment, LLM fine-tuning, GraphRAG; automatic remediation actions; more than two LLMs, languages other than French/English - **Goes live:** L3 Advisory production; users: UPTech service-desk technicians (2–5 in pilot, whole team at S6); walking skeleton (S2): suggestion service live in the ITSM tool (read-only), empty index; pilot (S4): top-3 similar tickets / articles (retrieval only, no LLM yet) shown to 2–5 technicians behind a feature flag; production (S6): grounded diagnosis with citations on every new ticket; technicians rate them - **Evaluated by:** data: UPTech's ITOps reference corpus first, then anonymised UPTech ITSM tickets (approved); time-ordered split (knowledge only from the training period). baseline: B2 LLM without retrieval, B3 plain hybrid RAG. metrics: Retrieval Recall@k and MRR, Grounded diagnosis accuracy GDA@k, Faithfulness, Response time Tresp, Cost per incident. Target: GDA@3 +10 points over B3. - **Read first:** Huyen, *AI Engineering* (2025); Manning, Raghavan & Schütze, *Introduction to Information Retrieval* (2008); Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (NeurIPS 2020) #### REF-AIOPS02 — Risk-gated remediation: when may the AI act alone? **Description:** AI can propose a fix for an incident, but executing it is risky. Build a remediation engine with three response modes: **apply** a low-risk, reversible action automatically; **prepare a change** (a merge request with the playbook) for human approval; or **comment** with referenced alternatives. The choice is made by a calibrated, risk-aware rule using confidence, blast radius on the service topology and reversibility. Automatic actions run only in a sandbox cluster; on production alerts the engine works in advisory mode (merge requests and comments). **Key tasks:** action catalogue (Ansible playbooks + rollback) · risk score and decision rule · "change as pull request" workflow in GitLab and ITSM · sandbox fault injection · safety metrics **Tools (preliminary proposal):** Python, Ansible/AWX, GitLab CI, ITSM, Prometheus, Kubernetes (sandbox) **Profile:** Engineering: DevOps / Cloud / Software Engineering, with an interest in AI safety and automation. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Sandbox only: one Kubernetes namespace + 3 VMs of the lab, never production; Fault injector for 6 fault types (CPU, memory, disk full, crashed pod, bad config, service down); Action catalogue: 6 failure types × correct action, gain, cost, reversibility, rollback (frozen at the end of S3); Ansible playbooks with tested rollback for each action; Risk score: calibrated confidence (Calibration and conformal sets) + Blast radius + reversibility; three-mode rule apply / merge request / comment (Response mode selection); Integrations: GitLab merge request for 'review' mode, ITSM comment for 'comment' mode, audit log; Replay of incidents + 30 injected faults; comparison with a fixed threshold (B5) - **Out of scope:** any target outside the sandbox; learned policies (reinforcement learning); a custom approval UI (GitLab and ITSM native screens only); more than 6 failure types - **Goes live:** L3 Advisory production (auto-actions in sandbox cluster only); users: on-duty technicians; GitLab reviewers; walking skeleton (S2): gate service live, reading production alerts, output to log only; pilot (S4): risk scores computed on live alerts and logged; reviewed weekly by 2 technicians; production (S6): advisory mode for all alert types in the catalogue; auto-apply stays in sandbox - **Evaluated by:** data: replayed incidents (UPTech's ITOps reference corpus) + injected faults in the sandbox. baseline: B5 fixed threshold; two-way gate. metrics: Unsafe action rate UAR, Safe automation rate SAR, Severity-weighted harm, Rollback success rate, Change approval rate and review time, Response mode distribution. Target: at UAR ≤ 1 %, more automation than B5. - **Read first:** Beyer et al., *Site Reliability Engineering* (2016); Nygard, *Release It!* (2nd ed., 2018); Morris, *Infrastructure as Code* (2nd ed., 2020) #### REF-AIOPS03 — Knowledge capture loop: every solved ticket teaches the service desk **Description:** Most solutions stay in technicians' heads or in closed tickets. Build a knowledge loop inside the service desk: when a ticket is solved, an assistant drafts a knowledge article from the resolution, the technician approves or edits it, and each suggested article later receives feedback ("did it help?"). Articles that age or fail lose reliability. Dashboards show how knowledge reuse changes resolution time. **Key tasks:** ITSM plugin for capture and feedback · AI article drafting with human approval · reliability and freshness scores · knowledge dashboards (reuse rate, freshness, MTTR) · pilot with the UPTech support team **Tools (preliminary proposal):** ITSM platform (plugin or API), Python/FastAPI, Wiki.js, PostgreSQL, Grafana, Keycloak SSO, local LLM **Profile:** Engineering or Master: Software Engineering / Information Systems; ITIL knowledge is a plus. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** ITSM platform plugin: 'create article from solution' on ticket solve, approve / edit by the technician, link article ↔ ticket ↔ category/CI; AI draft of the article with a local LLM (the technician always approves); Feedback 'did this article help?' on every suggested article; reliability score with forgetting (Knowledge capture update); Grafana dashboard: Knowledge capture rate KCR, Knowledge reuse rate KRR, Knowledge freshness index KFI; Replay on historical / synthetic tickets (loop on vs off) + a 3-week pilot with ≥ 2 UPTech technicians - **Out of scope:** Wiki.js migration or SSO rework; an advanced retrieval / RAG engine; a simple keyword search is enough to suggest articles; multi-entity / multi-language ITSM - **Goes live:** L1 Production; users: UPTech service desk (all technicians); walking skeleton (S2): plugin installed in the production ITSM, disabled by feature flag; pilot (S4): capture + approval for 2–5 technicians; production (S6): capture, feedback and dashboards for the whole team - **Evaluated by:** data: historical replay on the synthetic corpus + pilot tickets (anonymised). baseline: loop off (no capture, no reliability update). metrics: KCR, KRR, KFI, Proposal acceptance rate, Technician time per incident, Knowledge effect on MTTR (pilot: reported as observational). - **Read first:** ITIL 4 Foundation (Axelos, 2019); Consortium for Service Innovation, *KCS v6 Practices Guide*; Nonaka & Takeuchi, *The Knowledge-Creating Company* (1995) #### REF-AIOPS04 — Streaming observability lakehouse with data contracts and freshness SLOs **Description:** AI for IT operations is only as good as its data. Build the data backbone of the UPTech operations platform: metrics, logs, traces, tickets and the service topology flow through RabbitMQ into a lakehouse (bronze/silver/gold), with data contracts, quality checks and freshness objectives. Then measure how stale or missing data degrades incident detection and diagnosis. **Key tasks:** OpenTelemetry collection · RabbitMQ Streams ingestion · lakehouse (Iceberg/Delta on the self-hosted S3 object store) · topology from the ITSM CMDB · data contracts and freshness SLOs · degradation experiments **Tools (preliminary proposal):** OpenTelemetry, Prometheus, Loki, RabbitMQ Streams, Python consumers, Spark (batch), Iceberg/Delta, Ceph RGW or Garage (S3), dbt, Great Expectations/Soda, Grafana **Profile:** Engineering or Master: Data Engineering / Big Data / Cloud. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Sources: Prometheus metrics and Loki logs from ≥ 5 lab VMs, ITSM tickets, topology from an ITSM CI export; OpenTelemetry collector → RabbitMQ Streams; Lakehouse on the shared self-hosted S3 object store with **one** table format (Iceberg or Delta, chosen in S2): bronze / silver / gold, dbt for silver/gold; 4 data contracts (alerts, metrics, tickets, CIs) enforced; bad records quarantined; Freshness and completeness SLOs with Grafana alerts (Data freshness); One degradation experiment: delay and data loss vs detection quality - **Out of scope:** distributed traces at scale, Flink, multi-cluster high availability; NetBox / full CMDB synchronisation; a new ML detector (reuse the existing detector) - **Goes live:** L1 Production; users: UPTech ops team and data / AI consumers inside UPTech; walking skeleton (S2): collector + RabbitMQ stream + bronze table live on 1 VM; pilot (S4): ≥ 5 production VMs + ITSM tickets flowing, freshness dashboard; production (S6): all lab/prod sources agreed in charter, contracts enforced, SLO alerts to the owner - **Evaluated by:** data: lab telemetry + replayed corpus. baseline: current batch CSV replay (current). metrics: end-to-end latency p50/p95, throughput, freshness, contract violations caught, Detection lead time and diagnosis accuracy vs data age. - **Read first:** Kleppmann, *Designing Data-Intensive Applications* (2017); Reis & Housley, *Fundamentals of Data Engineering* (2022); Majors, Fong-Jones & Miranda, *Observability Engineering* (2022) #### REF-AIOPS05 — IT-operations benchmark: incident prediction and root-cause ranking **Description:** Build UPTech's reference benchmark of IT-operations data (metrics, logs, tickets, service topology, injected faults) and use it to evaluate and choose the detection and root-cause localisation models of the UPTech operations platform, with rigorous splits and baselines. The benchmark runs as an internal service, so every new model is compared on the same data before it goes to production. **Key tasks:** fault-scenario simulator · dataset documentation (datasheet) · time- and host-grouped splits · detectors (Isolation Forest, Random Forest, LightGBM, XGBoost) · topology-aware root-cause ranking (personalised PageRank) **Tools (preliminary proposal):** Python, pandas, scikit-learn, XGBoost/LightGBM, networkx, MLflow **Profile:** Engineering or Master: Data Science / AI / Applied Mathematics. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Corrected corpus generator with 6 fault scenarios and ground truth (root cause, resolution); Dataset release v1.0 (Parquet/CSV) with a datasheet and a licence; Protocol: time- and host-grouped splits, thresholds on validation only; 4 detectors: Isolation Forest, Random Forest, LightGBM, XGBoost + a rule baseline; Root-cause ranking with personalised PageRank on the topology (Topology-aware fault ranking) vs ranking by anomaly score - **Out of scope:** deep sequence models (extra after charter); real production data; online or streaming learning - **Goes live:** Internal benchmark service; users: UPTech data and AI teams; walking skeleton (S2): dataset repo + CI checks release-ready (private); pilot (S4): dataset v0.9 shared internally with UPTech teams; production (S6): dataset v1.0 released, benchmark job in CI - **Evaluated by:** metrics: PR-AUC, F1, Detection lead time, Root cause accuracy AC@k; bootstrap confidence intervals. - **Read first:** Géron, *Hands-On Machine Learning* (3rd ed., 2022); Huyen, *Designing Machine Learning Systems* (2022); Gebru et al., "Datasheets for Datasets" (Communications of the ACM, 2021) #### REF-AIOPS06 — Securing AI operations agents: telemetry guardrails, red-teaming and LLM observability **Description:** AI agents that read logs and tickets can be manipulated: an attacker can write instructions into a log line or a ticket. Build the security layer of the UPTech AI operations assistant: an "untrusted telemetry boundary" that masks dangerous fields, a red-team test suite of poisoned logs and tickets, and LLM observability (traces, cost, latency, failures). Measure how often attacks succeed with and without the guardrails. **Key tasks:** threat model (OWASP Top 10 for LLM apps) · input boundary and output policy checks · attack suite (prompt injection in telemetry) · LLM tracing and cost dashboards · fail-safe behaviour when the LLM is down **Tools (preliminary proposal):** Python, Ollama, Langfuse (self-hosted)/OpenTelemetry, Garak or PyRIT, Wazuh, Grafana **Profile:** Engineering or Master: Cybersecurity / AI / Software Engineering. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Threat model of the AI operations assistant (OWASP Top 10 for LLM applications); Untrusted telemetry boundary: masking / quoting of untrusted fields in logs and tickets (Untrusted Telemetry Boundary); Output policy check: allowed actions list, refusal of unknown tools; Attack suite of 50 poisoned logs / tickets, run in CI; LLM observability with Langfuse (or OpenTelemetry GenAI): traces, latency, tokens, cost, errors; Fail-safe behaviour when the LLM or the index is down - **Out of scope:** SIEM integration; training or fine-tuning detectors; securing the rest of the infrastructure - **Goes live:** L3 Advisory production (guardrails on the live assistant); users: users of UPTech's AI operations assistant (the existing prototype, redeployed in S2); walking skeleton (S2): Langfuse live, tracing the existing assistant; pilot (S4): boundary in log-only mode on live traffic; production (S6): boundary + policy checks enforced; attack suite in CI blocks releases - **Evaluated by:** baseline: boundary off. metrics: Attack success rate, Policy violations, Decision stability, Graceful degradation rate, latency overhead. - **Read first:** OWASP Top 10 for LLM Applications (latest version); Greshake et al., "Not what you've signed up for: indirect prompt injection" (AISec 2023); NIST AI Risk Management Framework 1.0 (2023) ### AI Engineering Projects #### REF-AISDLC01 — AI Project Manager: an AI-driven software lifecycle and release-batch manager **Description:** UPTech delivers many interconnected microservices (ThePortal and other products) through one GitLab and Argo CD pipeline. UPTech already has a project-management framework (hybrid PMBOK + Agile, with governance, registers and cost tracking on OpenProject and GitLab), but keeping it up to date, reviewing and releasing are still manual. Design and implement **UPTech's AI-driven SDLC** on top of this framework: an AI project manager that helps at every stage, from turning requirements into user stories with acceptance criteria to merge-request summaries and review checklists, release notes, sprint and status reports, and project registers (risks, issues, changes) kept up to date from GitLab and OpenProject. Its core is a **release-batch manager**: it maps dependencies between services, groups ready changes into safe production batches, scores the risk of each change and prepares the promotion from staging to production. Humans approve every merge and every deployment. **Key tasks:** AI-augmented SDLC process (stages, roles, gates) · GitLab assistant (story refinement, MR summary and review checklist, release notes) · project registers and weekly status reports from GitLab and OpenProject · service dependency map · release-batch planning and change risk scoring · promotion staging → production through GitOps with approval gates · delivery dashboard (DORA metrics, lead time, AI usage) **Tools (preliminary proposal):** Python, FastAPI, OpenProject (API), GitLab API and webhooks, GitLab CI, Argo CD, Kustomize, RabbitMQ, PostgreSQL, local LLM (self-hosted, CPU), Langfuse, Grafana **Profile:** Engineering or Master: Software Engineering / DevOps / AI. Interest in software delivery, LLM applications and process design. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** **AI-augmented SDLC built on UPTech's project-management framework** (governance, processes, registers, cost management): stages (idea → story → build → review → test → release → operate), roles, AI touch-points and human gates, written as a process guide and templates (issue, MR, release).; **GitLab assistant** (self-hosted service on GitLab webhooks):; story refinement: draft user stories and acceptance criteria from a requirement issue;; MR summary and review checklist posted as a comment (what changed, risks, missing tests);; release notes and sprint report generated from merged MRs and closed issues.; **Project registers and status reports:** sync with OpenProject (work packages, milestones) and GitLab (issues, MRs, pipelines); the AI proposes updates to the risk, issue and change registers and drafts the weekly project status report (progress, schedule, risks, decisions needed); the project manager validates.; **Release-batch manager:**; service dependency map built from the repositories (Maven modules, API contracts, RabbitMQ exchanges and queues, image versions);; change risk score per MR (size, files and services touched, test and coverage change, past failures), with an explanation;; batch planning: proposes which ready changes go to production together and in which order, respecting dependencies and a risk budget per batch;; prepares the promotion as a merge request on the GitOps repository (Argo CD + Kustomize overlays staging → production); a human approves and syncs.; **Delivery dashboard** (Grafana): DORA metrics, lead time per stage, batch size, AI suggestions accepted or rejected.; Pilot on 5–10 ThePortal services. - **Out of scope:** Autonomous merging or deploying without human approval.; AI generating feature code.; Tools other than GitLab and OpenProject (no Jira, no external SaaS); cost analytics and EVM dashboards; LLM fine-tuning.; Rebuilding the CI/CD platform or the clusters (existing GitLab CI and Argo CD are used as they are). - **Goes live:** L2 Controlled production: the assistant and the batch manager run on real repositories and releases; every merge and every deployment is approved by a human.; users: UPTech developers, reviewers and release managers; walking skeleton (S2): webhook service live, events logged; pilot (S4): assistant comments on 5 pilot repositories; production (S6): release batches proposed for real releases, promotion MRs approved by humans - **Evaluated by:** **Assistant quality:** share of MR summaries and checklists rated useful by reviewers; share of generated acceptance criteria kept; release-notes accuracy against the merged MRs (human check). **Risk score:** how well it ranks past changes that failed or were rolled back (AUC on history), with a simple baseline (MR size only). **Project management:** register freshness (days since last update), time to produce a status report before vs after, share of AI register updates accepted by the project manager. **Batches:** dependency violations caught before release, batch size, failed promotions. **Delivery:** DORA metrics (lead time, deployment frequency, change failure rate, time to restore) before vs after, review waiting time. **Cost:** LLM latency and tokens per MR on CPU; developer survey (time saved, trust). - **Read first:** PMI, *A Guide to the Project Management Body of Knowledge* (7th ed., 2021); Forsgren, Humble & Kim, *Accelerate* (2018); Humble & Farley, *Continuous Delivery* (2010) #### REF-AITEST01 — AI Tester: an AI-powered software testing framework **Description:** UPTech's microservices are tested with JUnit, Postman, SonarQube and k6, but writing and maintaining tests takes time and coverage is uneven. Build an **AI-powered testing framework** that plugs into GitLab CI: it generates unit tests for Spring Boot services and runs, checks and fixes them before proposing them; it generates and maintains the Postman collections run by **Newman** from the OpenAPI contracts, and builds end-to-end UI tests from user stories, with locators that repair themselves. It also selects the tests affected by each merge request, flags flaky tests and handles **test reports end to end**: every run is collected, published on the merge request, kept with its history and trends, triaged with AI, turned into defects when confirmed, and summarised in a test report for each release. Every generated test is proposed as a merge request and reviewed by a developer, and test quality is measured with mutation testing, not only coverage. **Key tasks:** LLM unit-test generator (generate → compile → run → fix loop) · Newman API tests (Postman collections) generated from OpenAPI · Playwright E2E tests from user stories with self-healing locators · test-impact selection per merge request · flaky-test detection · end-to-end test-report management (collection, history, triage, defects, release test report) · quality dashboard (coverage, mutation score, CI time) **Tools (preliminary proposal):** Java, JUnit 5, Mockito, PIT, Newman (Postman collections), Playwright, Python, local LLM (self-hosted, CPU), GitLab CI, SonarQube, Allure **Profile:** Engineering or Master: Software Engineering / Quality Assurance / AI. Interest in testing, Java and LLM applications. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** **Unit tests (Spring Boot):** LLM generator with a loop generate → compile → run → fix (max N attempts); only tests that compile, pass and add coverage or kill mutants are kept; proposed as a merge request.; **API tests:** generated from the OpenAPI contracts of the services (Newman (Postman collections)), including negative cases and Keycloak-secured endpoints.; **E2E UI tests:** Playwright tests generated from user stories for the Angular front-ends, with self-healing locators (fallback strategies, suggestions logged for review).; **Test-impact selection:** for each MR, run only the tests affected by the changed code, with a full run nightly.; **Flaky-test detection:** re-runs and history; flaky tests are quarantined and reported.; **Complete test-report handling:**; every run (JUnit, Newman, Playwright, PIT) produces standard reports (JUnit XML, HTML, Newman reporters);; reports collected in Allure with history and trends per service, and shown as GitLab test reports and an MR comment summary;; AI triage of failures: probable cause, similar past failures, new vs known failure;; a confirmed failure becomes a defect (GitLab issue or ITSM ticket) linked to the test, run and MR;; traceability user story → tests → results, and a **release test report** (HTML/PDF) generated for each release and archived;; notifications to the service owner for failures on `main`.; **Quality measurement:** coverage (JaCoCo/SonarQube), mutation score (PIT), CI time; dashboard and Allure reports.; **CI integration:** a reusable GitLab CI template; pilot on 3–5 ThePortal services. - **Out of scope:** Load and performance test generation (k6) and security testing (DAST): extras after the charter.; Mobile app testing.; Testing outside UPTech's own services; LLM fine-tuning. - **Goes live:** L1 Production: the framework runs in the GitLab CI of real ThePortal services; generated tests are merged only after a developer's review.; users: UPTech developers and reviewers; walking skeleton (S2): CI template with coverage and mutation score on 1 service; pilot (S4): generated tests proposed on 3 services; production (S6): framework in the CI of 3–5 services - **Evaluated by:** **Test quality:** coverage and **mutation score** before vs after on the pilot services; baseline = existing tests. **Generator quality:** share of generated tests that compile, pass, are kept by reviewers; attempts per useful test; CPU time per test. **Bug finding:** seeded-bug campaign (mutants or injected faults) detected by the new tests vs the old ones. **CI efficiency:** pipeline time with test-impact selection vs full runs; missed failures (target 0). **Test reports:** share of failures triaged correctly (checked by developers), time from failure to defect, completeness of release test reports. **Flakiness:** precision of the flaky-test detector on known flaky tests. **Developers:** short survey on usefulness and trust. - **Read first:** Beck, *Test-Driven Development: By Example* (2002); Meszaros, *xUnit Test Patterns* (2007); Crispin & Gregory, *Agile Testing* (2009) ### Development Projects #### REF-DEV01 — ThePortal: field-service app for technicians (event-ready for ERP) **Description:** ThePortal is UPTech's microservices suite for HR, logistics, sales, after-sales and call-center processes. Its After-Sales (SAV) microservice already handles complaints, plans interventions and assigns technicians. In 2027 we take it to the field: a mobile app for technicians (interventions, scheduling, offline mode, photos and signatures) with intervention events published so that client ERPs (Divalto, Sage) can be connected next. You will work on a real product used by clients, with code review and CI/CD. **Key tasks:** extend the SAV intervention service (scheduling, SLA, reports) · Flutter mobile app with offline sync · intervention events on RabbitMQ (outbox pattern), ready for ERP integration · Keycloak SSO and roles · automated tests and performance tests **Tools (preliminary proposal):** Java, Spring Boot, Spring Cloud (Gateway, Eureka), Keycloak, Angular, Flutter, MySQL, RabbitMQ, GitLab CI/CD **Profile:** Engineering or Master: Software Engineering, full-stack (Spring Boot + Flutter). **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Extend ThePortal's After-Sales (SAV) microservice for field work, reusing its complaints, intervention planning and technician assignment: scheduling for technicians, field status workflow, SLA timer, PDF intervention report; Flutter mobile app for technicians: my interventions, details, status update, photos, signature, offline cache with sync; Keycloak roles (dispatcher, technician, client) reused from ThePortal; Events published to RabbitMQ with the outbox pattern (`intervention.created / updated / closed`), ready for ERP consumers - **Out of scope:** ERP consumers for Divalto / Sage (extra after charter or PFE 2028); route optimisation, payments, inventory of spare parts; new admin dashboards beyond lists and filters; AI suggestion of technicians and detection of recurring failures (extra after charter) - **Goes live:** L1 Production; users: dispatchers and 5–10 technicians (UPTech or one pilot client); walking skeleton (S2): intervention service skeleton deployed in ThePortal production stack; pilot (S4): 2 technicians + 1 dispatcher use the app for real interventions; production (S6): all field technicians of the pilot; events on RabbitMQ - **Evaluated by:** functional acceptance tests with a pilot client user; sync latency and error rate; offline-sync conflict tests; p95 API latency under load (k6/Gatling); usability (SUS ≥ 70). - **Read first:** Evans, *Domain-Driven Design* (2003); Richardson, *Microservices Patterns* (2018); Newman, *Building Microservices* (2nd ed., 2021) #### REF-DEV02 — Octo: a proactive, trusted knowledge hub for any organisation **Description:** Every company has knowledge spread across people, tickets and documents, and no way to know what is still true. **Octo** is a self-hosted knowledge hub for any organisation, from a 20-person SME to a corporate group. Employees ask questions on general topics; critical topics are visible by role; engineers and auditors explore a topic before a mission. Anyone, newcomers included, can contribute; experts confirm, update or dispute. Each piece of knowledge gets a **trust score** from the evidence behind it. Octo is **proactive**: it detects contradictions, contested or outdated knowledge and unanswered questions, and asks the right **knowledge ambassador** for a judgment or a clarification. Part of the project is research: you design and compare trust and confusion-detection models. *This product belongs to its founders and is developed at UPTech: an IP and confidentiality agreement is signed at the start.* **Key tasks:** configurable organisation profile (domains, access levels, roles, ambassadors) · contribution and review workflow, fair to newcomers · trust scoring engine (Bayesian, expert-weighted, time decay, independence) · confusion detection (contradiction, contested, stale, gaps) with ambassador cases · role-based AI answers with citations and trust **Tools (preliminary proposal):** Python, FastAPI, PostgreSQL/pgvector, local LLM and NLI models (self-hosted), Keycloak, Angular or React, Langfuse, GitLab CI **Profile:** Engineering or Master: Software Engineering / AI / Data Science. Interest in knowledge management, probability and NLP. **More details** (a starting point; the final scope is agreed in your project charter): - **Design principles:** Trust measures evidence, not people; Newcomers can add value from day 1; Proactive, not passive; One product, any organisation; Self-hosted, private - **Fair to newcomers:** Content first; Fast review; Fast learning; Blind review option; Recognition, not ranking - **Proactive confusion detection:** Priority; Ambassador actions; Effects - **In scope:** Configurable organisation profile: domain taxonomy, access levels (2–5), roles via Keycloak groups/attributes (LDAP/AD federation), ambassadors per domain with fallback, review periods and decay per domain. Small and medium profiles delivered; corporate as a documented configuration.; Knowledge model with versions and full history; contribution and review workflow (create, update, confirm, dispute); newcomer review routing and SLA; notifications.; Trust engine: B0 and M1 in production with "why this score"; M2 implemented in the simulator for comparison.; Confusion detector with the 5 triggers above; ambassador case queue, actions, priority and weekly budget.; Permission-aware hybrid RAG Q&A (BM25 + dense, shared local LLM) with citations, trust badge, "under review" banner and "ask the ambassador" fallback; reader ratings.; Topic explorer for engineers and auditors: related items, trust, experts, open cases, gaps.; Initial content: ITSM knowledge base import; 10–15 pilot experts and 2–3 ambassadors in 3 domains at UPTech. - **Out of scope:** Actions and workflows (n8n, Ansible, ERP): the later agentic phase.; Briefing export (PDF), import of other sources (Portal docs, drives, e-mail): extras after the charter.; Multi-tenant SaaS hosting: one self-hosted deployment per organisation.; Mobile app, chat-tool bots, languages beyond French and English, LLM fine-tuning. - **Goes live:** L1 Production (role-based access); users: all UPTech employees (read, General); departments (Internal); pilot roles such as ops, engineers and auditors (Confidential); 10–15 experts and 2–3 ambassadors; walking skeleton (S2): configured UPTech profile, read and editor UI with Keycloak login; pilot (S4): experts and newcomers contributing in 3 domains; trust badges live; production (S6): open to all employees; confusion detection and ambassador queue live - **Evaluated by:** **Trust models (simulation with ground truth):** 50 synthetic contributors with known reliability per domain, including newcomers of high and low quality, one confident bad expert and a colluding team. Compare B0, M1 and M2 (and blind review on/off) on: AUC of true vs false items, and calibration (Brier score, ECE) time for a good newcomer's item to reach "trusted" false items that become "trusted" under collusion **Confusion detection:** precision and recall on injected contradictions, contested and stale items; time to resolution; ambassador load (cases per week vs budget). **Real pilot:** Spearman correlation between model trust and a panel of 3 domain owners on 50 items; newcomer contributions (share, acceptance rate, review delay); ambassador decisions and resolution time. **Q&A:** correctness, faithfulness, citation validity, p95 latency, cost per answer, access-leak rate (target 0). - **Read first:** Manning, Raghavan & Schütze, *Introduction to Information Retrieval* (2008); Jøsang, *Subjective Logic* (2016); Yin, Han & Yu, "Truth Discovery with Multiple Conflicting Information Providers on the Web" (KDD 2007) #### REF-DEV03 — Qima: a mentoring and internship platform that builds value **Description:** **Qima** (قيمة, "value") is a platform where everyone builds value together. You will build it: it connects mentors, interns, companies and training centres. Mentors publish topics and follow interns sprint by sprint; interns deliver their work linked to GitLab and get feedback; companies post real projects and follow their interns. UPTech will use it first to run its own PFE programme (topics, applications, weekly follow-up, evaluation grids). *This product belongs to its founders and is developed at UPTech: an IP and confidentiality agreement is signed at the start.* **Key tasks:** roles and profiles · topics and applications · selection grids · intern work plan, tasks and reviews · sprint deliveries linked to GitLab · evaluation grids and dashboards **Tools (preliminary proposal):** Spring Boot or NestJS, Angular or Next.js, PostgreSQL, Keycloak, GitLab API **Profile:** Licence or Engineering: Software Development, full-stack. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Roles: admin, mentor, intern, company contact; PFE workflow: topics → applications → selection grid → acceptance; Follow-up: charter, 8 sprints per intern, sprint delivery linked to the GitLab tag and sprint note, late-delivery flag, weekly check-in notes; Evaluation grids (mid-term, final) and a cohort dashboard for mentors; E-mail notifications (deadline reminders, missed delivery) - **Out of scope:** Courses and e-learning content: UPTech's e-learning platform (Learnhub) already covers them; Qima links to it.; training-centre role, credit wallet and payments (extra after charter); built-in video calls (external links only), skill-matching algorithm, mobile app - **Goes live:** L1 Production; users: UPTech mentors and the PFE 2027 interns; walking skeleton (S2): app skeleton live with Keycloak; pilot (S4): topics, applications and selection grids used by mentors with real cohort data; production (S6): sprint follow-up linked to GitLab used for the PFE 2027 cohort; ready for the PFE Book 2028 call - **Evaluated by:** pilot on PFE 2027 cohort: task completion, weekly check-in rate, SUS usability score, mentor time saved vs forms/email. - **Read first:** Martin, *Clean Architecture* (2017); Vernon, *Domain-Driven Design Distilled* (2016); Krug, *Don't Make Me Think* (3rd ed., 2014) #### REF-DEV04 — Offline-first point of sale (POS) for small and medium stores, connected to ThePortal **Description:** Small and medium stores need a cash register that never stops selling, even when the internet is down. Build an **offline-first point-of-sale application**: cashiers scan products, take payments, print receipts, handle returns and close their shift without any network. Every operation is stored safely on the device and **synchronised automatically** with the server as soon as it can be reached, with no lost or duplicated sale. Catalogue, prices and stock come from ThePortal, UPTech's business platform, and sales flow back to it. You will deploy it in a real client store in Tunisia. **Key tasks:** cashier app (scan, cart, payments, receipts, returns, shift close) · local database and operation outbox · sync protocol (idempotent, delta catalogue, conflict rules) · offline login and data encryption · receipt printer and barcode scanner · small back-office · chaos testing of network failures **Tools (preliminary proposal):** Flutter, SQLite, Spring Boot, MySQL, RabbitMQ, Keycloak, Angular, ESC/POS printers, GitLab CI/CD **Profile:** Engineering or Master: Software Engineering (mobile + back-end). Interest in distributed systems and offline-first design. **More details** (a starting point; the final scope is agreed in your project charter): - **Offline-first design:** Local first; Idempotent operations; Receipt numbering offline; Conflict rules; Delta sync; Long offline; Security; Clock safety - **In scope:** **Cashier app** (Flutter, Android tablet and Windows desktop):; product search and barcode scan (USB/Bluetooth scanner), cart; quantity and simple line or ticket discounts; payment methods recorded (cash with change, card recorded as paid, other); split payment; receipt printing (ESC/POS) and optional e-receipt by e-mail at sync; returns and refunds; cashier shift open and close with a cash count and an end-of-day (Z) report; Local encrypted database, outbox, sync engine with the rules above, offline PIN login, device registration.; Sync service (Spring Boot + MySQL): idempotent ingest, delta catalogue, stock ledger, publication of sales and stock events to ThePortal through the provided contracts.; Multi-terminal per store (up to 3) and multi-store (up to 5) for the pilot.; **Small back-office** (Angular): stores, terminals, cashiers and roles, sync status per terminal, sales and Z-report views, CSV export.; Chaos test suite for the network and devices. - **Out of scope:** Integration with card payment terminals (TPE) and online payment.; Fiscal certification and e-invoicing. The Tunisian fiscal requirements are listed in S1 and the design keeps them possible, but certification is not part of the internship.; Loyalty programmes, advanced promotions engine, gift cards, multi-currency.; Purchasing, supplier orders, inventory counting, accounting integration (beyond CSV export).; iOS app, restaurant or table mode, self-checkout. - **Goes live:** L1 Production: the main cash register of at least one client pilot store in Tunisia (1–3 terminals); users: cashiers and the store manager of the pilot store; UPTech back-office users; walking skeleton (S2): pilot device registered, catalogue downloaded from the production sync service; pilot (S4): parallel run in the pilot store; production (S6): POS is the main register of the pilot store - **Evaluated by:** **Reliability (chaos campaign):** network cut during a sale, during sync and during a batch upload; app killed and device rebooted mid-operation; clock changed; 3 terminals offline for 3 days selling the same products. Metrics: lost or duplicated operations (target 0), stock correctness after merge, time to full resync. **Scale:** simulation of 10k sales and 50k products; sync time vs batch size and connection quality. **Pilot store:** tickets per day, average checkout time vs the old register, sync delay, incidents, Z-report differences. **Usability:** cashier task tests (sale, return, shift close) and SUS ≥ 70. - **Read first:** Kleppmann, Wiggins, van Hardenberg & McGranaghan, "Local-first software" (Onward! 2019); Kleppmann, *Designing Data-Intensive Applications* (2017); Shapiro, Preguiça, Baquero & Zawirski, "Conflict-free Replicated Data Types" (SSS 2011) #### REF-DEV05 — Solar client and installer platform: maintenance, monitoring and catalogue for a Tunisian PV distributor **Description:** A Tunisian distributor of photovoltaic equipment (panels, inverters, batteries, solar pump drives) works with a network of more than 60 approved installers across the country. Build its digital platform: a **mobile app for clients** to register their installation, activate the warranty, request maintenance or emergency support and follow their system's **real-time production and health**; a **mobile app for installers** to receive and close interventions in the field, even offline; and a **web back-office** to dispatch requests, manage warranties and see the whole installed base. The platform also detects under-performing systems and turns them into maintenance requests before the client notices. **Key tasks:** client app (installation, warranty, maintenance requests, monitoring, catalogue, find an installer, quote request) · installer app (interventions, checklists, photos, commissioning report, offline mode) · monitoring from inverter data (production, uptime, alarms, expected vs actual yield) · smart alerts and SAV dispatch · back-office and dashboards · French / Arabic **Tools (preliminary proposal):** Flutter, Spring Boot, Keycloak, RabbitMQ, MySQL, TimescaleDB, Angular, inverter and solar-yield APIs **Profile:** Engineering or Master: Software Engineering (mobile + back-end). Interest in energy, IoT data and field operations. **More details** (a starting point; the final scope is agreed in your project charter): - **Features for the Tunisian market:** Installation registry and warranty; Smart maintenance requests; Performance monitoring; Proactive alerts; Catalogue and quote; Administrative follow-up; Agriculture; Installer app; Languages - **In scope:** **Client app** (Flutter, Android + iOS build, FR/AR): sign-up and login (Keycloak), installation registration by QR / serial scan, warranty and documents, maintenance requests with photos and status tracking, monitoring screens, catalogue, installer map, quote request with sizing estimate, notifications.; **Installer app** (same Flutter code base, installer role): assigned interventions, checklists, photos, serial scan, commissioning report (PDF), signature, offline queue with sync.; **Back-office** (Angular): request queue and dispatch by governorate, warranty and replacement (RMA) follow-up, installed base, installer network, catalogue management, dashboards (requests, SLA, failures by product and region, alerts).; **Monitoring integration:** connector to the inverter monitoring API (or its data export) for the pilot installations; daily aggregation; expected yield from PVGIS; underperformance and alarm rules generating alerts.; **Services:** Spring Boot microservices on the UPTech stack (Gateway, Eureka, Keycloak, RabbitMQ, MySQL; TimescaleDB for production data); reuse of ThePortal's SAV microservice where it fits.; Pilot: ~50 client installations and 5–10 approved installers in 2–3 governorates. - **Out of scope:** Online payment, financing and bank credit integration.; Other inverter brands than the first one (connector design kept generic; more brands are extras).; Full e-commerce, ERP integration, accounting.; Agricultural pumping beyond a read-only status view.; WhatsApp or other SaaS messaging (self-hosted notifications and e-mail; SMS gateway as an extra). - **Goes live:** L1 Production: pilot clients and installers use the apps for real requests; apps published under the client's Google Play / App Store accounts.; users: the distributor's clients (homes, businesses, farms), approved installers, the distributor's SAV and sales teams; walking skeleton (S2): back-end and login live, internal app build; pilot (S4): real maintenance requests from 10 clients handled by 3 installers; production (S6): ~50 installations monitored, apps in the stores - **Evaluated by:** **Service:** time from request to intervention and to resolution, first-time-fix rate, before (phone and form) vs after (apps), on the pilot. **Monitoring:** share of installations with valid data; accuracy of expected yield vs measured; precision and recall of underperformance alerts (checked against installer visits and injected test cases). **Adoption:** warranty activations through the app, requests through the app vs phone, installer response time. **Usability:** task-based tests with 5 clients and 5 installers (SUS ≥ 70), including Arabic users. **Quality:** crash-free rate, offline sync errors (target 0 lost interventions). - **Read first:** Evans, *Domain-Driven Design* (2003); Richardson, *Microservices Patterns* (2018); Kleppmann, Wiggins, van Hardenberg & McGranaghan, "Local-first software" (Onward! 2019) ### Data Projects #### REF-DATA01 — DataCollect: fast, reliable survey and statistical data collection **Description:** Surveys and field studies are often slow and hard to trust. Build a configurable data collection platform: questionnaires defined by configuration, an offline web app for field agents, real-time quality control (consistency rules, paradata such as interview duration and GPS, outlier and fabrication detection), sampling and weighting, and dashboards that publish results within hours. *This product belongs to its founders and is developed at UPTech: an IP and confidentiality agreement is signed at the start.* **Key tasks:** questionnaire designer (config-driven) · offline web collection (PWA) with sync · streaming quality checks and fraud detection · weighting and margin-of-error computation · dashboards **Tools (preliminary proposal):** PWA (React or Angular), Spring Boot or FastAPI, RabbitMQ, ClickHouse/PostgreSQL, dbt, Superset, Python (pandas, statsmodels) **Profile:** Master or Engineering: Data Engineering / Statistics / Software. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Questionnaire defined by configuration (YAML/JSON): question types, skips, validation rules; Offline-first web app (PWA) for field agents with sync; Idempotent ingest API (no duplicate rows) into PostgreSQL or ClickHouse; Quality: consistency rules + paradata (duration, GPS, timestamps) + fabrication detection (rules + Isolation Forest); Weights and margin of error for simple random and stratified samples; Superset dashboard with time-to-result - **Out of scope:** LLM narration of results (extra after charter); native mobile app, complex sampling designs (clusters, multi-stage), multi-language questionnaires - **Goes live:** L1 Production (client survey campaign; internal UPTech survey as fallback); users: field agents and the survey client (or UPTech staff); walking skeleton (S2): ingest API + one form live; pilot (S4): pilot questionnaire with 3–5 agents; production (S6): one real campaign live end to end - **Evaluated by:** simulated field campaign (≥ 50k responses, injected fabricated interviews); precision/recall of fraud detection; ingest latency; time-to-result; estimate error vs ground truth. - **Read first:** Groves et al., *Survey Methodology* (2nd ed., 2009); Lohr, *Sampling: Design and Analysis* (latest edition); Kleppmann, *Designing Data-Intensive Applications* (2017) #### REF-DATA02 — Project and IT cost performance analytics (EVM + FinOps) **Description:** Build UPTech's analytics for project delivery and IT costs. Connect project tools (GitLab/Jira, timesheets) and infrastructure usage (VMware, Kubernetes) into one data model, compute Earned Value indicators (cost and schedule performance), the cost of each service and client, and forecasts. Interactive dashboards help managers see which projects drift and where infrastructure money goes. **Key tasks:** data mesh–style data products per domain · EVM (PV, EV, AC, CPI, SPI) · showback/chargeback of infrastructure per service and client · forecasting (cost and delay) · dashboards **Tools (preliminary proposal):** PostgreSQL, dbt, Airbyte, Apache Superset, Python, GitLab API, VMware/Kubernetes usage exports **Profile:** Licence or Master: Business Intelligence / Data Analytics / Information Systems. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Sources: GitLab API (issues, milestones), timesheet export (CSV), VMware and Kubernetes usage exports; Data model in PostgreSQL with dbt (one data product per domain: projects, effort, infrastructure); Earned Value indicators (PV, EV, AC, CPI, SPI, EAC) for ≥ 5 past or ongoing projects; Showback of infrastructure cost per service and per client (cost model documented); 3 dashboard pages (projects, infrastructure cost, forecast) in Apache Superset - **Out of scope:** OKR and KPI performance management of people and teams: ThePortal's Performance module already covers it.; migration to Jira or ClickUp, setting up a PMO; public cloud billing unless an export exists; budgeting / approval workflows - **Goes live:** L1 Production; users: UPTech managers (projects, infrastructure); walking skeleton (S2): dbt project + Superset live with one source; pilot (S4): EVM pages for 2 managers; production (S6): all 3 pages, nightly refresh, data checks alert the owner - **Evaluated by:** data quality checks; forecast error (MAPE) on past projects; manager review of dashboards (task-based usability test); share of infrastructure cost allocated (target ≥ 90 %). - **Read first:** PMI, *A Guide to the Project Management Body of Knowledge* (7th ed., 2021); Fleming & Koppelman, *Earned Value Project Management* (latest edition); FinOps Foundation, FinOps Framework (latest version) ### Embedded Solution #### REF-RFID01 — Smart RFID stock: reader integration, stock events and demand forecasting **Description:** Extend UPTech's RFID inventory solution from scanning to a smart stock system, using UPTech's RFID devices only (UHF readers and tags, no extra boards): a reader connector filters and de-duplicates tag reads, events flow through MQTT to the stock platform, the stock platform keeps a full movement history, and machine-learning models forecast demand and flag anomalies (shrinkage, misplaced items, abnormal consumption). **Key tasks:** reader integration (LLRP or reader SDK, read filtering, de-duplication, buffering) · MQTT event pipeline · stock service and movement history · forecasting and anomaly detection · dashboard and alerts **Tools (preliminary proposal):** UHF RFID readers and tags (LLRP or reader SDK), MQTT, Spring Boot, Angular, PostgreSQL/TimescaleDB, Python **Profile:** Licence or Engineering: Embedded Systems / IoT / Software. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Reader connector for 1 UHF RFID reader (LLRP or the reader's SDK), running on the UPTech platform: read filtering, de-duplication, buffering when the network or the platform is down; MQTT events → existing stock platform (Spring Boot) for stock updates and movement history; Alerts and dashboard (Angular) for stock levels and anomalies (rules); Demand forecast (Prophet vs a naive baseline) on historical or simulated movements - **Out of scope:** ERP and e-commerce synchronisation (extra after charter); multi-site, multi-reader orchestration; any hardware other than the RFID readers and tags (no extra boards, no custom hardware) - **Goes live:** L1 Production (one pilot zone); users: stock keepers of the pilot zone; walking skeleton (S2): reader connector + MQTT + dashboard skeleton in the pilot zone; pilot (S4): live stock for the pilot zone, 2 users; production (S6): alerts and forecast for the pilot zone - **Evaluated by:** read accuracy and duplicate rate in a test zone; event latency tag → dashboard; stock accuracy vs manual count; forecast MAPE vs a naive baseline; anomaly detection precision on injected cases. - **Read first:** Hyndman & Athanasopoulos, *Forecasting: Principles and Practice* (3rd ed., 2021); MQTT 5.0 specification (OASIS); Kleppmann, *Designing Data-Intensive Applications* (2017) ### DevOps & Platform Projects #### REF-DEVOPS01 — Platform engineering: a secure internal developer platform on Kubernetes **Description:** UPTech runs its own CI/CD pipelines and Kubernetes clusters. Turn them into a product for developers: an internal developer platform where a team creates a new service from a template and gets, in minutes, a repository, a secure pipeline, GitOps deployment, secrets and monitoring. Security is built in: signed images, SBOMs, policy-as-code and vulnerability gates. **Key tasks:** developer portal (Backstage) and golden-path templates · GitOps with Argo CD for staging and production (Kustomize overlays, ApplicationSet, approval in production) · supply-chain security (SBOM, signing, Kyverno policies) · secrets with Vault · DORA metrics dashboard **Tools (preliminary proposal):** Kubernetes, Argo CD, GitLab CI, Backstage, Kyverno, Trivy, Cosign, Syft, HashiCorp Vault, Kustomize, Helm, Prometheus, Grafana **Profile:** Engineering or Master: DevOps / Cloud / Security. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Backstage developer portal with 2 golden-path templates (Spring Boot service, Angular front-end); GitOps with Argo CD extended from dev to **staging and production**: Kustomize overlays per environment, an ApplicationSet generating the environments, merge-request approval and manual sync in production, GitLab webhook for immediate sync; Secure pipeline template: SAST, Trivy scan, SBOM (Syft), image signing (Cosign); 5 Kyverno policies (signed images only, no root, resource limits, labels, no latest tag); HashiCorp Vault (already in place) for the template apps' secrets; DORA metrics dashboard for 2 pilot applications - **Out of scope:** infrastructure provisioning with Crossplane / Terraform; cost dashboards (OpenCost) — extra after charter; multi-cluster, migration of all UPTech applications (2 pilot apps only) - **Goes live:** L1 Production; users: UPTech developers + all PFE 2027 repos; walking skeleton (S2): Backstage live with the software catalogue; pilot (S4): 2 pilot apps on the golden path; production (S6): all new PFE 2027 services created from templates; policies enforced - **Evaluated by:** DORA metrics before/after (deployment frequency, lead time, change failure rate, MTTR); time to bootstrap a new service (target < 15 min); policy violations blocked; critical CVEs in running images. - **Read first:** Humble & Farley, *Continuous Delivery* (2010); Forsgren, Humble & Kim, *Accelerate* (2018); Skelton & Pais, *Team Topologies* (2019) ### IT & Security Projects #### REF-IT01 — Security operations centre (SOC) integrated with the service desk **Description:** Build and run UPTech's security operations centre (SOC) on open-source tools, fully integrated with the service desk. A SIEM (Wazuh) collects and correlates logs from servers, network and applications; intrusion detection watches the network; detection rules are mapped to MITRE ATT&CK and proven with simulated attacks. Every security alert becomes an ITSM incident with the right priority, an investigation and response playbook and an escalation path, and the SOC is measured like a real one: time to detect, time to respond, false positives. Vulnerabilities are detected and hosts hardened, backups and recovery are tested, and agents, rules and playbooks are deployed as code (Ansible) and documented. **Key tasks:** SIEM (Wazuh) and network IDS (Suricata) · detection engineering mapped to MITRE ATT&CK, tested with simulated attacks · alert → ITSM incident with SLA, response playbook and escalation · SOC processes: triage, investigation, incident response, on-call · vulnerability detection and CIS hardening · backup and disaster-recovery tests · SOC dashboards (MTTD, MTTR, false positives) · Ansible automation **Tools (preliminary proposal):** Wazuh, Suricata, Sophos XG, ITSM, Prometheus, Grafana, Ansible, Atomic Red Team, VMware **Profile:** Licence, Master or Engineering: Cybersecurity / Networks / Systems, with a strong interest in blue-team operations and incident response. **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Wazuh manager + agents on ≥ 10 hosts; Suricata on one network segment; Detection rules mapped to MITRE ATT&CK, with a coverage matrix; Security alerts → ITSM incidents with priority mapping, a linked response playbook and an escalation path; SOC operating model: triage, investigation, incident-response and escalation procedures, on-call with the IT owner (runbook); Vulnerability detection (Wazuh) and CIS hardening of the monitored hosts; 10 attack scenarios simulated (MITRE ATT&CK, e.g. Atomic Red Team) and measured; Backup and restore test for 2 critical services (RTO / RPO measured); Security and SLA dashboard - **Out of scope:** Zero-Trust redesign, Terraform, high availability, firewall reconfiguration; 24/7 staffed monitoring (the SOC runs in business hours, with on-call by the owner) - **Goes live:** L1 Production; users: UPTech IT / security owner; walking skeleton (S2): Wazuh manager live, 1 agent; pilot (S4): ≥ 5 production hosts monitored, tickets to the ITSM tool in test queue; production (S6): ≥ 10 hosts, Suricata, tickets in the real queue, on-call by the owner - **Evaluated by:** detection tests with a scenario list (MITRE ATT&CK techniques simulated, e.g. with Atomic Red Team): detection rate, mean time to detect (MTTD), mean time to respond (MTTR), false-positive rate; ticket creation time; RTO/RPO measured in restore tests; CIS benchmark score before/after. - **Read first:** Anderson, *Security Engineering* (3rd ed., 2020); MITRE ATT&CK framework; CIS Critical Security Controls v8 ### Design Projects: Marketing, Graphic Design and UI/UX These four projects are for **marketing, graphic design and UI/UX** profiles, not for developers. Their main goal is always marketing, graphic design or UI/UX work: research, concepts, identity, interfaces, campaigns and their results. A project can be extended with a small development mission (for example the design tokens or a landing page in code) when it is agreed in the project charter, but this is never its main goal. #### REF-DESIGN01 — UPTech design system and UX for the operations platform **Description:** UPTech's internal tools look and behave differently, and ThePortal modules (call center, performance) already have mock-ups made in different files. Create one design system — colours, typography, components, icons, accessibility rules — and use it to redesign the key screens of an AI-assisted service desk: how an AI suggestion, its evidence and its confidence are shown, and how a technician approves or rejects it. Test the designs with real technicians. **Key tasks:** UX research with support technicians · design tokens and component library in Penpot, handed over to the developers · "explainable AI" patterns: evidence, confidence, approve/reject · accessibility (WCAG 2.2 AA) · usability tests **Tools (preliminary proposal):** Penpot, Style Dictionary (design tokens), usability testing tools · optional development extension: Storybook **Profile:** Licence or Master: UI/UX Design / Digital Media / Graphic Design. A UI/UX project, not a development project: the developers build the screens from your designs. Basic HTML/CSS is a plus and allows an optional extension (the components in Storybook). **More details** (a starting point; the final scope is agreed in your project charter): - **In scope:** Start from the existing ThePortal mock-ups (Call Center and Performance modules) and move them into one Penpot library.; UX research: 5 interviews / observations with support technicians; Design tokens + 25 components in Penpot, handed over to the developers (tokens file, specs, usage rules); Optional development extension, only if agreed in the charter: the components in Storybook for Angular, with the DEV team; 6 key screens of the AI operations assistant: suggestion, evidence, confidence, approve / reject, history, knowledge article; Accessibility audit (WCAG 2.2 AA); 2 rounds of usability tests (5 users each) - **Out of scope:** building production front-ends; logo or brand redesign - **Goes live:** L1 Production (design system used by the product teams); users: DEV and AIOps teams; walking skeleton (S2): Penpot project live and shared with the product teams; pilot (S4): tokens + first components used in 2 pilot screens of UPTech's service desk; production (S6): library v1 used by 2 product teams - **Evaluated by:** usability tests (5–8 users): task success, time on task, SUS; accessibility audit; adoption: components used by 2 product teams. - **Read first:** Norman, *The Design of Everyday Things* (revised ed., 2013); Frost, *Atomic Design* (2016); Krug, *Don't Make Me Think* (3rd ed., 2014) #### REF-DESIGN02 — Launch campaign for a new product **Description:** A new product is about to reach the market, and it needs a launch campaign that people remember and act on. You will design and run it end to end: audience and message research, the campaign concept (big idea, key messages, visual line), and the content: key visual, landing-page design, social media series, a product demo video with short cut-downs, an e-mail sequence and a sales kit. You then publish the campaign in phases (teaser, launch, follow-up), measure it with self-hosted analytics and improve it while it runs. *The product name is shared after the interview, under a confidentiality agreement.* **Key tasks:** audience and competitor research · campaign strategy and concept · key visual and content system · demo video and motion cut-downs · landing page and e-mail designs · phased publishing · A/B tests and campaign analytics **Tools (preliminary proposal):** Penpot (self-hosted), Inkscape or Illustrator, GIMP or Photoshop, Kdenlive or After Effects, Matomo, Listmonk or Mautic, Formbricks **Profile:** Licence or Master: Digital Marketing / Graphic Design / Visual Communication. A marketing and design project, not a development project: the web team builds the landing page from your designs. A portfolio is required; motion skills are a plus. **More details** (a starting point; the final scope is agreed in your project charter): - **Confidentiality:** NDA signed **before** the product name or any material is shared (after selection, before day 1). Work stays in a private GitLab repository (Git LFS for media) on UPTech infrastructure; no public cloud drives and no AI image or video services that upload material. Nothing is published before the owner's written go for each phase. - **In scope:** Research: 5 interviews with target users or customers, an audit of 8–10 competitor launches, 2–3 audience personas.; Campaign strategy: objectives and KPIs, audience, positioning message, channels (website, LinkedIn and other organic social, e-mail, events or demos), phased calendar (teaser, launch, follow-up).; Concept: a big idea, a key message plus 5 supporting messages (FR/EN), and a visual line built on the provided brand identity.; Content:; key visual in all formats; landing-page design (desktop and mobile) handed to the web team; 15–20 social posts and 3 carousels; one 60–90 s demo video plus 3 short cut-downs (15 s); a 3-mail launch sequence; a sales kit (one-pager, 8–10-slide deck, event roll-up); Measurement: UTM plan, Matomo goals and dashboard, A/B tests (2 visuals, 2 e-mail subject lines), a short post-launch perception survey.; Campaign playbook for future launches (templates and process). - **Out of scope:** Creating or changing the product's brand identity or name.; Paid advertising (ad accounts and budgets), influencer contracts.; Building or coding the website (the web team builds the landing page from the design).; Print production and event logistics. - **Goes live:** L1 Production: the campaign is published on the product's channels. If the owner sets the public launch after the internship, the go-live is the teaser phase plus the full, approved launch kit scheduled in the publishing calendar.; users: target customers and prospects; the product, sales and web teams; walking skeleton (S2): tracking and the e-mail list work end to end (test visit and test sign-up recorded); pilot (S4): teaser published to a first audience, results visible in Matomo; production (S6): launch published on all planned channels - **Evaluated by:** **Reach and engagement:** impressions and engagement rate per channel and per phase. **Conversion:** landing-page visits → sign-ups or demo requests (rate vs the target in the charter); e-mail open and click rates. **A/B tests:** difference between variants, with sample size and confidence stated. **Perception:** post-launch survey (≥ 30 respondents) on message recall and attribute match with the positioning. **Process:** content delivered on time vs the publishing calendar; owner satisfaction at closure. - **Read first:** Sharp, *How Brands Grow* (2010); Neumeier, *The Brand Gap* (2005); Kohavi, Tang & Xu, *Trustworthy Online Controlled Experiments* (2020) #### REF-DESIGN03 — Complete brand identity for a new digital product (confidential) **Description:** A new digital product is about to launch, and it needs a brand from scratch. You will build its complete identity: brand strategy (positioning, values, personality), visual identity (logo system, colours, typography, iconography, imagery), verbal identity (tagline, tone of voice), a UI kit as design tokens for the product teams, and the launch kit (website and app visuals, social media, presentation and document templates, a short motion video). You test the identity with real target users and see it go live. *The product name is shared only after the interview, under a confidentiality agreement.* **Key tasks:** discovery workshops and competitor audit · brand platform · logo system and visual identity · tone of voice · UI kit and design tokens · brand guidelines · launch kit · user testing of concepts **Tools (preliminary proposal):** Penpot (self-hosted), Inkscape or Illustrator, GIMP or Photoshop, Scribus, Kdenlive or After Effects, design tokens, self-hosted survey tools **Profile:** Licence or Master: Graphic Design / Visual Communication / Branding / Marketing. A design project, not a development project: the product team applies your design tokens in the code. A portfolio is required. **More details** (a starting point; the final scope is agreed in your project charter): - **Confidentiality:** The intern signs an NDA **before** the name or any material is shared (after selection, before day 1). Work happens only in a **private** GitLab repository (access: intern, mentor, product owner). No portfolio, social media or school use of the work until the product is launched **and** the owner approves in writing. All deliverables and rights belong to the product owner (stated in the internship agreement). - **In scope:** Discovery: 2 workshops with the product team, 5 interviews with target users, competitor and market audit (8–10 brands).; Brand platform: purpose, positioning, values, personality, audience personas, brand story.; Visual identity: logo system (primary, secondary, symbol, small sizes, monochrome), colour palette (WCAG AA contrast checked), typography (licence-free or licensed fonts), iconography style, imagery and illustration rules.; Verbal identity: tagline, tone of voice, writing rules (FR/EN), 10 key messages.; UI kit: design tokens (colours, type, spacing, radius, elevation) + 20 core components in Penpot, handed to the product team.; Brand guidelines (≈ 30–40 pages, PDF + web page).; Launch kit: app/website hero visuals, favicon and app icons, 10 social templates, presentation and document templates, e-mail signature, one 30–45 s motion video.; 2 rounds of concept testing with target users. - **Out of scope:** Creating the product name (the name is given), trademark registration, legal checks.; Building the website or the app front-end (done by the product team, using the tokens).; Print production, merchandise, paid advertising campaigns. - **Goes live:** L1 Production: the brand is applied in the live product (design tokens in production) and launch assets are published. The public launch date belongs to the owner; if it is after the internship, the go-live is the production theme behind a feature flag plus the approved launch kit.; users: product team (tokens, UI kit), marketing (launch kit), target users (tests); walking skeleton (S2): token pipeline from Penpot or JSON into the product theme works; pilot (S4): chosen identity visible to pilot users in staging; production (S6): brand tokens live in the product - **Evaluated by:** Concept test (round 1, ≥ 30 target users): preference, fit with the brand attributes (semantic differential), first impressions. Recall and perception test (round 2): 5-second test (name and logo recall), attribute match vs the brand platform, comparison with 2 competitors. Consistency audit: 20 assets checked against the guidelines (target ≥ 95 % conform). Accessibility: contrast and legibility at small sizes. Owner and product team acceptance (structured review). - **Read first:** Wheeler, *Designing Brand Identity* (5th ed., 2017); Neumeier, *The Brand Gap* (2005); Airey, *Logo Design Love* (2nd ed., 2014) #### REF-DESIGN04 — Re-branding of an existing product for an external client (confidential) **Description:** An existing product of one of our clients has outgrown its brand. You will lead its re-branding from start to finish. First you audit the current brand and what users think of it, and decide what to keep (brand equity) and what to change. Then you design the new identity and plan the migration of every touchpoint: website, application UI, documents, social media and signage. Finally you roll it out with the client's teams and measure perception before and after. *The client and product are shared after the interview, under a confidentiality agreement.* **Key tasks:** brand audit and asset inventory · user and stakeholder perception study · evolution-or-revolution strategy · new visual and verbal identity · design tokens for the product UI · migration plan and rollout · before/after measurement **Tools (preliminary proposal):** Penpot (self-hosted), Inkscape or Illustrator, GIMP or Photoshop, Scribus, Kdenlive or After Effects, design tokens, self-hosted survey tools **Profile:** Licence or Master: Graphic Design / Visual Communication / Branding / Marketing; interest in client work and project management. A design project, not a development project: the client's teams apply the new identity in their code. A portfolio is required. **More details** (a starting point; the final scope is agreed in your project charter): - **Confidentiality:** NDA signed **before** the client's name or any material is shared (after selection, before day 1). Private GitLab repository (intern, mentor, client contact); files on UPTech infrastructure (Git LFS); no public cloud drives and no AI image services that upload client material. No portfolio or public use until the new brand is public **and** the client approves in writing. All deliverables and rights belong to the client (internship agreement + client contract). - **In scope:** Brand audit: current identity, all touchpoints (asset inventory with owner and priority), competitors.; Perception study "before": survey (≥ 50 users or customers), 5 stakeholder interviews, 5-second recall test.; Strategy: brand equity map (what to keep, evolve, drop), evolution vs revolution decision with the client, updated brand platform.; New identity: logo evolution, palette, typography, iconography, imagery, tone of voice.; Design tokens + updated UI kit (20 core components) for the product team.; Migration plan: priority list of touchpoints, before/after mock-ups, rollout calendar and checklist, old-asset retirement.; Rollout support for the top-priority touchpoints (product UI theme, website, document and presentation templates, social profiles), done with the client's teams.; Brand guidelines v2 (PDF + web) and an announcement kit (internal and customer communication, 1 short motion video).; Perception study "after" on the same panel or a matched sample. - **Out of scope:** Changing the product name, trademark filing, legal checks.; Building or recoding the client's website or app (the client's team applies the tokens; the intern supports).; Print production, signage manufacturing, paid campaigns. - **Goes live:** L1 Production: the new identity is live on the client's priority touchpoints. Rollout dates are agreed with the client in the charter.; users: the client's customers and staff; the client's product and marketing teams; walking skeleton (S2): current brand as tokens in the client's staging theme; pilot (S4): new identity in staging for pilot users; production (S6): new identity live on the first priority touchpoints - **Evaluated by:** **Brand equity before vs after:** recall in a 5-second test, attribute match (semantic differential on 6–8 attributes), preference and trust, with ≥ 50 respondents per wave. **Recognition kept:** share of respondents who still recognise the product from the new logo (target set in the charter). **Rollout:** share of priority touchpoints migrated on time; consistency audit (≥ 95 % of 30 assets conform). **Accessibility and performance:** contrast report; page performance not degraded. **Client satisfaction:** structured review at closure. - **Read first:** Wheeler, *Designing Brand Identity* (5th ed., 2017); Sharp, *How Brands Grow* (2010); Aaker, *Managing Brand Equity* (1991) ## Selection process and key dates | Step | What happens | When | |---|---|---| | 1. Apply | Fill in the **web form** only: track, first-choice project (REF code), CV, school, internship length, alone or as a pair | until **25 November 2026** | | 2. E-mail | We confirm by e-mail; from now on all communication is by e-mail | after the deadline | | 3. Mission | You receive a short mission (2–4 h) based on the project you selected | end of November 2026 | | 4. Reply | You reply to the mission e-mail with your work (repository link or archive) | within **7 days** | | 5. Shortlist | Replies are reviewed: correctness, quality, how you measured your result, clarity, initiative, on time | mid-December 2026 | | 6. Interview | 30–45 min: you present your mission (10 min), then technical and motivation questions; pairs together | December 2026 | | 7. Offer | Offer by e-mail, internship agreement, NDA or IP agreement where needed | Dec 2026 – Jan 2027 | | 8. Start | Kick-off day, reading list, project charter in your first two weeks | **February 2027** | ## How to apply 1. **Apply only through our web form: [forms.gle/LuaMtB8aXrd8t6VW8](https://forms.gle/LuaMtB8aXrd8t6VW8)**, before **25 November 2026**. Choose your track and your first-choice project (REF code). You can apply alone or as a pair (say so in the form); we confirm whether the project can take two students. 2. **We contact you by e-mail** with all the details. 3. **You receive a short mission** based on the project you selected. Reply to it by e-mail within 7 days. 4. **Shortlisted candidates are invited to an interview**, where you present your mission. Using AI for your mission is fine: say how you used it, and be ready to explain every part of your work. We are not trying to trap you; we want to find the project where you will do your best work. ## FYI - **Application deadline: 25 November 2026.** - You may be offered another project that fits your profile better than your first choice. - Applications are accepted **only through the web form**. After that, all communication is by e-mail; applications sent by e-mail or LinkedIn are not considered. - Your reply to the project mission decides whether you are shortlisted for an interview. - Internships are full time, **hybrid** (office visits based on project needs), start in **February 2027** and last **3 to 6 months** depending on your school. - The internship is **unpaid**. A motivation bonus (training, certification or subscription) may be offered at the end, based on results. - The tools listed for each project are a **preliminary proposal** and may change after the study phase. - Some projects are for real clients or founder-owned products: a confidentiality (NDA) or IP agreement is signed before the start, and names are shared after the interview. ## Contact Website: https://www.uptech.com.tn/pfe-2027.html · Centre Urbain Nord, 1082 Tunis · LinkedIn: https://www.linkedin.com/company/uptechtn/