The program runs during the demonstration. The screen looks tidy, the sample data produces the expected output and the group is relieved. Then the teacher changes one condition and asks a student to explain the result. The learning becomes much easier to see.
In a French BUT Informatique SAÉ, useful evidence connects a need with the student’s choices, implementation, tests and explanation. Start with the actual task and competency framework, preserve a few revealing traces of your work, and show what you can understand and do when a requirement changes.
This guide uses the ministry’s published BUT Informatique national programme, labelled 2022 and updated in 2023, checked on 22 October 2026. Confirm the programme and assessment arrangements applying to your IUT, pathway and cohort. The software cases are original fictional exercises, not official SAÉ briefs, production systems or predictions of an assessment result.
Find your next learning step
Start with the curriculum relationship, inspect the software cases or check what your project evidence can actually establish.
ROUTE 1 · CHAPTERS 1–3
Understand the learning structure
Separate resources, SAÉ, a working product and demonstrated competence.
ROUTE 2 · CHAPTERS 4–6
Follow a project decision
Translate needs, test boundaries and explain a design revision.
ROUTE 3 · CHAPTERS 7–9
Assemble useful evidence
Show individual contribution, reflect and handle a changed requirement.
ROUTE 4 · CHAPTERS 10–12
Repair and check
Match support to the actual difficulty and try an independent case.
ROUTE 5 · CHAPTERS 13–14
Prepare the next step
Resolve practical questions and read the official programme.
Full chapter index · Independent learning check · Education parent guide
Full chapter index
Understand the learning structure · Chapters 1–3
Follow a project decision · Chapters 4–6
Assemble useful evidence · Chapters 7–9
Repair and check · Chapters 10–12
Prepare the next step · Chapters 13–14
CHAPTER 1 OF 14 · Understand the learning structure
1. Understand the relationship between resources, SAÉ and portfolio
The published BUT Informatique programme describes SAÉ as situations d’apprentissage et d’évaluation. They bring resources together in a task related to a professional problem and contribute to learning and assessment. The portfolio supports a student’s reflective demonstration of developing competence through selected traces.
Resources can include knowledge and methods taught in different parts of the programme. A project may require programming, mathematical reasoning, communication and an understanding of a user’s need. Their usefulness appears when the student selects and combines them appropriately, rather than merely recognising each topic in a separate lesson.
BUT stands for bachelor universitaire de technologie; an IUT is an institut universitaire de technologie. In this setting, the national programme gives a shared framework while the student’s actual teaching team supplies the applicable project brief and assessment arrangements. Read both. Knowing the qualification’s name does not tell you which evidence a particular task requires.
For example, a test record might be relevant to implementation and checking, while a client clarification might reveal interpretation and communication. Neither trace should be assigned to a competency merely because it looks professional. Explain the connection using the actual framework and ask the teaching team when that mapping is uncertain. The portfolio is an account of developing capability, supported by evidence whose relevance can be examined.
The product is one part of the evidence. A working application can show that something functions under particular conditions. It does not automatically reveal who made an important decision, whether the tests were adequate or whether the student understands how the result was obtained.
A portfolio makes those questions discussable. It can preserve a design choice, a test that exposed a misunderstanding, a revision and an explanation of what changed. Selection matters: a large collection of screenshots may establish activity without making a learning claim clear.
Begin with the actual competency framework and task brief. Ask which learning is being targeted, what evidence is expected and how individual contribution will be considered. A personal reflection tool should help you understand those requirements, not silently replace them with a private checklist.
This article’s central question is therefore practical. What can the student now explain or perform, and which trace of the project helps another person inspect that capability? Keeping the question visible can change how the work is planned, documented and reviewed from its first stage.
CHAPTER 2 OF 14 · Understand the learning structure
2. Read a need before deciding on a feature
A user describes a problem in everyday language. The student has to decide what behaviour a program should provide. This translation contains assumptions, and those assumptions should be examined before coding makes them expensive to change.
In our fictional case, a student group is asked to build a small classroom tool for comparing scheduled activities. It uses invented records and operates only as an educational exercise. The initial request says that the tool should identify overlapping activities. The word overlapping needs a precise meaning before the group can implement it.
Do two activities overlap when one ends exactly as the other begins? Can a record have an end earlier than its start? Are the activities all on one day? These are not decorative details. Different answers produce different behaviour from the same-looking feature.
Write a small set of examples before choosing a rule. An activity from 10:00 to 11:00 and another from 10:30 to 11:30 clearly share time. Two activities separated by an hour do not. A pair meeting at 11:00 exposes the boundary condition the original request left open.
Clarification is part of the technical work
A novice may believe that asking a question shows weakness. In fact, an unanswered ambiguity can be carried directly into code. A useful clarification states the uncertainty and its consequence: should the endpoint pair be reported, and how would that affect the tool’s intended use?
Record the agreed interpretation in language the group can check. Do not let the first implementation become the only specification. If the behaviour later needs revision, the record should show whether the requirement changed or the code failed to implement the original agreement. Those are different project events and different learning opportunities.
CHAPTER 3 OF 14 · Understand the learning structure
3. Separate a working demonstration from a competence claim
A demonstration can be successful for several reasons. The student may understand the method deeply. They may also be following a familiar sequence, using a narrow example or relying on another group member’s work. The visible output alone does not distinguish these possibilities.
Ask the learner to trace one invented record through the program. Which condition is checked first? What does the comparison mean? Why is the result appropriate for this case? The explanation can reveal whether symbols in the code represent understood relationships or merely a pattern that happened to work.
Then change a condition. Keep the underlying task recognisable while removing the exact example used in the demonstration. Can the student predict the behaviour before running the program? Can they explain an unexpected result? A changed case tests a different aspect of understanding from reproducing the prepared demonstration.
The formal assessment still belongs to the programme and teaching team. These questions are learning diagnostics. They should not be presented as an unofficial pass test or a promise that a particular portfolio item satisfies an entire competency.
An honest competence claim has a scope. “I can explain and test the overlap rule for the agreed same-day records” is more inspectable than “I am competent in software development.” The smaller claim can then be connected with the actual framework, feedback and further learning needed.
This distinction also makes support fairer. If the student understands the rule but struggles with syntax, teach the implementation issue. If the code is correct but the rule is misunderstood, return to the relationship. More coding of the same pattern may not repair a missing concept.
CHAPTER 4 OF 14 · Follow a project decision
4. Worked case: an endpoint exposes an assumption
The fictional group agrees that activities are represented as intervals including the start and excluding the end. Under that convention, 10:00–11:00 and 11:00–12:00 do not overlap. The convention belongs to this exercise; it is not a universal rule for every scheduling system.
Using start and end values, two valid intervals overlap when the first start is earlier than the second end and the second start is earlier than the first end. For this exercise, a valid interval also has an end strictly later than its start; zero-duration records are outside the agreed input domain. Both relationships matter. A student should be able to explain why one comparison alone can incorrectly include a pair that lies entirely before or after the other.
No code language is required to test the reasoning. Compare 10:00–11:00 with 10:30–11:30. Both starts lie before the other interval’s end, so shared time exists. Compare 10:00–11:00 with 11:00–12:00. The second start is not earlier than the first end, so the agreed boundary convention excludes overlap.
Now test a pair with one activity wholly inside another: 10:00–13:00 and 11:00–12:00. They overlap even though neither start and end pair is identical. A rule based only on equal starting times would miss this case. The example helps the student distinguish the relationship from a superficial pattern.
The useful evidence is not only a screenshot showing the final answer. Preserve the agreed convention, a small test table and the explanation of the boundary case. That trace shows the connection between requirement, implementation and checking.
If the requirement later changes to allow a preparation gap between activities, the original rule is no longer the whole problem. The group needs a new agreement and revised tests. A student who can identify that change is learning to distinguish a defect from a changed need, an important part of dependable software work.
The time representation can create a separate failure
The overlap rule assumes that earlier and later values are compared meaningfully. Now imagine that the group stores times as text. A simple character-by-character comparison of “9:30” and “10:00” can place the first string after the second, because it begins with 9 rather than 1. A correct interval relationship can therefore produce wrong behaviour when its values have an unsuitable representation.
For this same-day teaching exercise, the group agrees to represent valid clock times as minutes after midnight. Nine thirty becomes 570; ten o’clock becomes 600. The conversion is hours multiplied by sixty, plus minutes. The smaller number now corresponds to the earlier time. The original text can remain available for display and checking, while the numerical representation serves the comparison.
This is a new decision to document. The learner should explain why the representation fits the agreed input domain, rather than report that converting to numbers mysteriously fixed the software. A useful trace includes the two original strings, their converted values and the result of the comparison. It isolates the representation issue from the overlap rule.
Conversion also needs validation. A parser returning a number does not establish that every input describes an allowed clock time. The group must check the agreed format and valid hour and minute ranges, then follow its declared response to unsupported data. It should not silently accept a minute field of seventy because an arithmetic operation can still be performed on it.
Finally, test an interval with equal start and end values. Under the exercise’s stated non-empty-interval convention, this record is invalid before overlap is considered. Test that response separately from the valid endpoint pair. The distinction helps the student see why “the times are equal” has different meanings when it occurs within one record and between two otherwise valid activities.
CHAPTER 5 OF 14 · Follow a project decision
5. Worked case: invalid input needs a declared response
The group receives an invented record with an end time earlier than its start time. One student’s first reaction is to swap the values automatically. That produces a plausible-looking interval, but it changes the supplied information without an agreed basis.
Another student suggests treating the record as an overnight activity. That is also an interpretation, not a fact established by the data. The exercise was defined for same-day activities. The group must decide how invalid or unsupported inputs should be handled rather than inventing a convenient meaning.
With the teacher acting as the fictional client, they agree that the tool will flag the record for correction and exclude it from the comparison until resolved. This is a teaching decision for the example, not a prescribed production-system practice. Its value is that the behaviour becomes explicit and testable.
The student then separates validation from the overlap rule. Validation asks whether the record belongs to the agreed input domain. The overlap rule asks about the relationship between valid records. Mixing the two can make the program difficult to explain and the test results difficult to interpret.
A learning record might preserve the original assumption, the clarification and a test of the agreed response. It should identify who made the decision and what the student implemented. “Fixed the data” is too vague; it hides whether information was corrected with evidence or simply altered to make the demonstration work.
For transfer, change the invalid condition. A record now has a missing start time rather than reversed values. Can the student identify the unresolved requirement and seek a clear response without mechanically applying the earlier repair? The test checks judgement about input meaning, not just memory of one error message.
CHAPTER 6 OF 14 · Follow a project decision
6. Worked case: a group result needs an individual explanation
The application is a group product. One student clarified requirements, another implemented comparisons, a third prepared the interface and a fourth organised tests. All may have learned, but the shared output does not make their individual contributions identical.
In this fictional group, Louis implemented the overlap comparison using a suggestion from a classmate. His portfolio should acknowledge that source of help and explain what he now understands. Merely listing the file he edited would not reveal whether he can reconstruct the relationship independently.
At review, Louis explains the two comparisons using a fresh pair of intervals. He then identifies a test that would expose a rule checking only matching start times. This gives a more useful account of his learning than claiming that he designed every aspect of the application.
Another student, Salma, created the test cases. She can explain why boundary and containment cases matter, but initially cannot trace the implementation. Her next learning need differs from Louis’s. A shared project mark or screenshot should not erase that distinction in the teaching conversation.
The group can keep a concise contribution record: decision, contributors, support received and relevant trace. This is a suggested learning practice, subject to the course’s arrangements. It is not a substitute for the teaching team’s assessment of individual evidence.
An honest account of collaboration can be stronger than a story of solitary achievement. Professional software work relies on combining contributions while preserving responsibility. The educational task is to make each learner’s developing understanding visible inside the shared work, so that support and challenge address what the person actually needs next.
CHAPTER 7 OF 14 · Assemble useful evidence
7. Select traces that can carry an argument about learning
A trace becomes evidence when it helps support a particular claim. A commit, screenshot, diagram or feedback note does not explain its own significance. The student needs to identify what it shows, how it connects with the targeted learning and what it leaves uncertain.
Begin with a claim small enough to inspect. “I learned to test boundary conditions” can be supported by the endpoint example, an earlier omission and a later fresh test. A folder containing every test run may be less useful if the important change is difficult to find.
| Trace selected | Learning claim it may support | Further question |
|---|---|---|
| A clarified requirement | I identified an ambiguity before implementation | What behaviour changed because of the clarification? |
| A boundary test | I checked a case the happy-path example missed | Why does that case matter? |
| A revision with a reason | I corrected a specific misunderstanding | Can I explain the corrected relationship? |
| A contribution account | I can distinguish my work and received support | What can I now do independently? |
| A changed-task attempt | I can use the idea beyond the original demonstration | Which new condition still needs learning? |
The table is an original reflection aid. Use the actual framework and local assessment instructions to decide what evidence is required and acceptable.
Preserve the context of a trace. An image without the task, data convention or explanation may be difficult to interpret later. A few accurate sentences can make the evidence much more useful. Do not reconstruct a confident history that hides an unresolved assumption or invents an earlier version that never existed.
The Akashi architecture graduation-project guide offers a useful comparison: a drawing can show a spatial relationship while leaving other claims untested. In programming, a demonstration likewise needs an explanation of what its tests establish. The evidence must fit the discipline and the particular learning claim.
CHAPTER 8 OF 14 · Assemble useful evidence
8. Use portfolio reflection to explain development
Reflection should connect an earlier approach with a later change in understanding or performance. Description establishes what happened. Analysis explains why a feature mattered. Evaluation examines whether the response addressed the problem. A next step identifies what still needs practice or investigation.
For the interval project, an entry might explain that the student originally tested only obvious overlaps. The endpoint example revealed an unstated convention. After clarification, the student revised the rule and added containment and boundary cases. A later independent explanation showed which part of the relationship had become understood.
That account is stronger than “I improved my programming” because the change is visible. It is also more useful for planning. The teacher can identify whether the next challenge concerns data representation, test design, implementation or communication.
The programme’s portfolio approach is not simply a gallery of finished products. Its educational value lies in making the student’s development arguable through selected traces. Ask how the evidence supports the claim, rather than treating the presence of many files as proof of broad competence.
Keep the reflection yours
Use language you can explain. Feedback can help you clarify a sentence, but a polished account written by somebody else may conceal the learning that needs to be assessed. Follow the programme’s authorship and tool-use requirements, and acknowledge relevant contributions accurately.
Our Irish Transition Year portfolio guide explores a different programme with a broader developmental purpose. Its rules do not apply to BUT. The useful comparison is selecting evidence that reveals a change, while keeping the actual purpose and requirements of each portfolio clear.
CHAPTER 9 OF 14 · Assemble useful evidence
9. Handle a changed requirement without losing the earlier reasoning
Suppose the fictional client now wants the tool to show not only whether activities overlap but how much time they share. The old yes-or-no result remains relevant, but the output requirement has changed. The student needs to identify which part of the reasoning can be reused and which part needs extension.
For overlapping intervals, the shared time begins at the later start and ends at the earlier end. The difference between those values gives the overlap duration under the exercise’s assumptions. For 10:00–11:00 and 10:30–11:30, the shared portion runs from 10:30 to 11:00: thirty minutes.
The learner should explain that relationship before writing a compact formula. If the values are converted to minutes from an agreed origin, the units must remain consistent. A difference between a clock display and a number of minutes is not meaningful without a clear representation.
Test a non-overlapping pair as well. A calculation that produces a negative value needs an agreed interpretation, not a claim of negative shared time. The program’s response should fit the defined task and input domain. The teaching point is to connect the numerical operation back to its meaning.
Record the extension separately from any correction of the original implementation. If the old program satisfied the original yes-or-no request, the new duration output is a changed requirement. Keeping the distinction visible helps the student understand project evolution and describe progress honestly.
Then try a different domain in class, such as two fictional availability periods. The vocabulary changes, but the interval relationship may remain useful. Ask which assumptions still hold and which must be checked again. Transfer means recognising the structure while investigating the new conditions, not blindly copying code into every superficially similar situation.
When a program behaves unexpectedly, locate the first point where the student’s understanding becomes uncertain. Did they interpret the need incorrectly, choose an unsuitable representation, implement the rule wrongly or misread the output? These difficulties can produce the same wrong result while requiring different repairs.
A requirement problem needs clarification. A representation problem needs a clearer account of what a value means. An implementation problem may need tracing and a small test. An interpretation problem needs the result connected back to the task. Repeating the whole project can obscure the specific learning need.
If the student can follow a demonstration but cannot begin a fresh task, reduce the problem to its first decision. Ask what is known, what is required and which relationship might connect them. A partially worked example can help, followed by another independent attempt with different values.
If tests all resemble one another, ask what kind of mistake they would fail to reveal. The interval project needs more than several obvious overlaps. Boundary, containment, separation and invalid-input cases expose different assumptions. The appropriate set depends on the actual requirement, not a universal number of tests.
If documentation becomes extensive but uninformative, choose one claim and the trace most relevant to it. Explain the connection in a short paragraph. This can teach evidence selection more effectively than demanding longer descriptions of every file.
If a group member remains dependent on another person’s explanation, arrange a supported reconstruction of the relevant decision. Then use a changed case to see what the learner can now do alone. The aim is to improve understanding inside the collaborative project, rather than simply distribute more tasks or hide uneven learning behind the group’s completed product.
Students can keep ownership of the reasoning: what the need means, why a method fits and what a result supports. They can bring a specific question to feedback and distinguish what they attempted independently from support they received. This makes the next intervention easier to choose.
Teachers can make expert decisions visible. Model how an ambiguous word becomes a testable requirement or how a boundary case challenges a rule. Explain the reason for a test rather than presenting testing as a ritual performed after the real work of coding.
Peers can check explanations and compare approaches while preserving contribution and authorship. A classmate may offer an alternative, but the learner should still understand why it works. Copying the solution without the relationship can make the immediate output correct and the next task just as difficult.
Families can ask about the learning without needing to judge every line of code. “Which decision changed after testing?” or “What can you explain now that was unclear earlier?” invites an account of development. Avoid treating a visually elaborate application as an automatic sign of deeper competence.
For students connecting university study with company practice, the existing ZHAW practice-integrated computer science guide examines another educational arrangement. Its Swiss programme requirements remain separate. The useful bridge is planning learning around real responsibilities while checking what the learner understands and can demonstrate.
Support should become more targeted as the student develops. Early guidance may explain a relationship in detail. Later feedback may ask the student to justify a choice or identify a missing test. Increasing independence is visible when the learner can make those checks themselves and seek help for the new uncertainty rather than for every familiar step.
CHAPTER 12 OF 14 · Repair and check
12. An independent check with a fresh software need
Try this fictional exercise without copying the interval solution. A classroom tool groups invented book records by category. The request says that category names should be treated consistently. One record uses “History,” another “history,” and a third has no category. What needs clarifying before implementation?
A useful answer identifies separate questions. Should differences in letter case be ignored? How should missing categories be represented? Are categories drawn from an agreed list or created freely? The student should not assume that one convenient data-cleaning rule answers every part of the need.
Now suppose the teacher agrees to ignore letter case but preserve the original display text in the record. What should a test establish? It should show that grouping behaves as agreed while the original information remains available as required. A screenshot of one category does not establish both properties for every case.
Next, the tool groups the two history records correctly but silently drops the missing-category record. Is that automatically acceptable? No. The response must be judged against the agreed requirement. If that condition was never settled, the first repair is clarification, followed by an implementation and test that make the decision explicit.
Finally, identify a learning claim and a useful trace. The student might show how they separated normalisation for grouping from preservation of original data. A small before-and-after record and an explanation could support the claim. It would not establish competence in every aspect of data management.
The changed exercise tests whether the learner can connect need, representation, behaviour and evidence beyond the scheduling example. If the relationship remains unclear, teach the missing part with a smaller case, then offer another fresh task. Independent understanding should grow from the repair rather than be assumed from a corrected final output.
CHAPTER 13 OF 14 · Prepare the next step
13. Questions students and families often ask
Is a SAÉ simply a large coding assignment?
The published programme connects SAÉ with the mobilisation of resources in a professionally relevant problem and the development of competence. The actual task may involve more than code. Read the brief and framework to understand which decisions, evidence and learning are being targeted.
Does a working program prove I understand it?
It provides evidence about its behaviour under the tested conditions. Understanding also becomes visible through explanation, prediction, checking and a changed task. Ask what the program’s success establishes and which questions about your own contribution or reasoning remain unanswered.
Should the portfolio contain every screenshot?
Follow local requirements, but select deeper evidence for a clear purpose. A trace should support an identifiable claim about development. A smaller, well-explained selection may be more informative than a large archive in which the important decision cannot be found.
How do I describe help from another student?
Accurately. Identify the contribution and explain what you subsequently understood or performed. Collaboration can support learning without making every group member’s contribution identical. Follow the course’s authorship rules and avoid presenting received work as independently created.
What if a requirement changes after the first version?
Record the original agreement, the new need and the effect on the plan. Distinguish a changed requirement from a defect in the earlier implementation. Then revise the relevant behaviour and tests, with guidance appropriate to the task and assessment arrangements.
Can one example establish a whole competency?
This article makes no such claim. The formal framework and assessment conditions determine what must be demonstrated. A learning example can reveal a particular judgement and help plan the next step without replacing the teaching team’s broader assessment.
Are these the official national SAÉ tasks?
No. The scheduling and book-category cases are original teaching examples. They illustrate reasoning within a project. Use your actual IUT’s brief, applicable national programme and assessment instructions for the work you must undertake and submit.
CHAPTER 14 OF 14 · Prepare the next step
14. Sources and the next useful project review
The main source is the French ministry’s BUT Informatique national programme, 2022 updated in 2023. Its general framework explains SAÉ and the portfolio; its first-year examples show connections between needs, implementation, testing and resources. The document was checked on 22 October 2026. Local briefs, cohort arrangements and assessment decisions require confirmation with the IUT.
The ministry’s certification, training and competency-portfolio resource provides wider context for the relationship between learning and evidence. This guide does not infer a universal software project, exact local weighting or guaranteed qualification outcome from that broader discussion.
All numerical times, records, client requests and student accounts here are fictional. The interval convention is explicitly part of the teaching exercise. It should not be imposed on a real scheduling product without clarifying that product’s own requirements and responsibilities.
At the next review, bring one requirement, one decision and one revealing test. Explain how they connect. Identify what you did, which support you used and what a fresh example shows about your understanding. Then ask which next learning task would most strengthen the contribution.
Return to the Gold Standard of Education parent for the wider purpose. A project becomes education when the learner can use its relationships beyond the demonstration: interpreting a new need, choosing a justified method, checking the result and explaining the limits of the claim.
Contents · Previous chapter · Continue with the Education parent